As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label password. Show all posts

Just read Visualize your password reuse on Mozilla Lab by Paul Sawaya about this addon, here is a screenshot of my test profile in Firefox:

http://i.imgur.com/wQThC.png

The graph use d3.js and its interactive, you can draw or click, and even to check the clear text of the passwords.

Again, its not the passwords I use daily. No way I will show you that even this is just a visualization. They are a lot can be learned from a simple graph.

I found this is helpful to help your realize how your security sense based on your passwords. A crazy nut of security should have a totally non-connecting graph.

Each green dot is a password, blue dot is the website. Square orange box connecting passwords means those passwords are similar, which by general guidelines of security that should be avoid.

Using different password for different website, but when you are testing. Well, you know abc123 comes in handy. As you can guess, those two only distinct passwords and websites are the actual passwords, and I am not going to tell you what they are. :)

PS. abc123 may just be a misleading to let you believe I use that for testing, please dont use it to hack into my account. ;)

I have made my Gentoo working without PAM. I didn't test xlock before, but then I found I couldn't log in with my password. So I changed to vc1 and killed xlock.

After looked into xlockmore (xlock's package name), I understood I needed to enable xlockrc use flag.

Ran it from command line, I was prompted for entering key (the password):

$ xlock -mode blank
  Key: 
Again: 
$ cat .xlockrc 
Something

Now session lock is back.

When SXXT happens, it's time to change your password.

How so? Yesterday, I happily committed my code, which is for backing up layout templates for blogs on Blogger.com. After committing done, I saw my Google password when switched back to editor. Anyone who is in normal mental state would loudly yell with "SXXT!" or "FXXK!". I did. I forgot to empty the strings, which have my gmail and password before committed. Actually, I thought I did, because I got prompted for my email and password, therefore I believed that I had emptied two strings. Obviously, I didn't.

The Subversion repository is at Google Code hosting. I deleted the project (sort of making project private) and requested a reset to my repository. Meanwhile, I used svnsync to retrieve all revisions to my computer. After resetted, I tried to sync back without the idiot revision, but I can't get the job done. Later, I manually re-committed the rest of revisions.

From this incident, I have learnt:
  • Never allow to put password or other sensitive contents in source, must use a configuration file with secured permission in home directory or similar way if needed
  • Always check status and diff before committing
  • Always grep the diff before committing
  • If SXXT still happens, do not reset if there is only one password involved. Changing the password, instead, would be much easier; and removing the SXXT and committing again
Even you can perfectly "rollback", you still can not assure that no one has checked out your SXXT as their juicy fruit or no bots has crawled your SXXT and indexed it.

When SXXT happens, you can appreciate it for reminding you of changing password and the opportunity to have new blog post to share your SXXT mood.