Live data from Hacker News

Don't Store Passwords, Generate Them When Needed

16s.us

31–40 of 64 posts

Re: Don't Store Passwords, Generate Them When Needed

#31
My solution is to use Keepass. It stores passwords in an encrypted database file which I store in Dropbox - that solves the machine synchronization problem.

The main database is protected by a passphrase and/or keyfile (any file which won't change e.g. ~/Dropbox/Photos/2008/France/Photo5.jpg). One advantage of this is that a simple keylogger will be stumped by the keyfile - even if your passphrase is recorded an attacker still needs Photo5.jpg to decrypt the database.

It's originally a Windows app (http://www.keepass.info/), but is open-source and there's a fully featured Linux/OSX port called KeepassX (http://www.keepassx.org/)

Re: Don't Store Passwords, Generate Them When Needed

#33
post #28

"And by the way, if after reading this you still wish to use a traditional password manager, I suggest that you put your passwords into a plain text file and encrypt it with GPG or use Password Safe." Having recently had some significant trouble with a lost online banking password, I've been thinking about keeping all my passwords in an encrypted file stored in various places (I don't like the idea of using a passwor…

You can use keepass which is open source and cross platform.

http://keepass.info/download.html

It's much more convenient than a text file you cipher and decipher and it's more secure as well. A text file is prone to error (wrong copy/paste, forgot to cipher the file, etc.)

Re: Don't Store Passwords, Generate Them When Needed

#36
I use the same scheme with minor variations. The most annoying thing is "secure password requirements" ("your password must have digits", and it happened that generated one didn't have a single digit) or limits (I'm fine with encoding-agnostic 7-bit-ASCII-only, but "8 chars max" or "may only contain alphanumerics" frustrate me) on some sites, which force me to step away from this scheme.

In fact, there are way too many exceptions out there in the wild. One still needs a notebook of some sort for such cases.

Also, the last time I've logged into Bitbucket (I [almost] don't use it, but I have the account) I forgot that I logged there using OpenID instead of login-password pair. :)

Re: Don't Store Passwords, Generate Them When Needed

#37
post #4

However, this IS a master password only with a salted hash added on top. From the FAQ it uses a phrase like "Tubby loves tacos!facebook" runs it through SHA1 and spits out Facebook's password. Someone who shoulder surfs your keyphrase can now use this technique to generate passwords for any site, whereas using something like Password Safe or the various other password storage methods would need to both shoulder surf…

It's not only been done, "master password with a salted hash" is broken. If I can convince you to log in to face.com ("Tubby loves taco's!face"), I can find the hash of "Tubby loves taco's!facebook". This is because SHA1("Tubby loves taco's!facebook") is just SHA1-sub(SHA1("Tubby loves taco's!face"), "book"). See "length extension attack" for more details.

More generally, hash functions are collision-resistant, but the output is not (pseudo)random.

Re: Don't Store Passwords, Generate Them When Needed

#38
post #29
post #13

Earlier quoted context omitted.

There are about 50,000 commonly used words in English. That means that each word has an entropy of about 15.6 bits. (Probably less since some words are far more common than others.) Using a typical 4 word phrase gets you about 62 bits of entropy. In contrast a password can select from a set of about 72 characters. i.e. 6.1 bits per letter. Using an 10 character password gets you about 61 bits of entropy. So they seem…

So they seem reasonably comparable... It would be nice to redo the calculation while accounting for how common each word is, and also that special characters are used less often in passwords. I know this was a rough estimate, but I think it is way, way off. Passphrases are not usually generated by random choice of English words but are instead a particular, meaningful English sentence. This means not only are you dea…

I quite agree. I just don't have any easy way to calculate it.

Re: Don't Store Passwords, Generate Them When Needed

#39
post #4

However, this IS a master password only with a salted hash added on top. From the FAQ it uses a phrase like "Tubby loves tacos!facebook" runs it through SHA1 and spits out Facebook's password. Someone who shoulder surfs your keyphrase can now use this technique to generate passwords for any site, whereas using something like Password Safe or the various other password storage methods would need to both shoulder surf…

It's not only been done, "master password with a salted hash" is broken. If I can convince you to log in to face.com ("Tubby loves taco's!face"), I can find the hash of "Tubby loves taco's!facebook". This is because SHA1("Tubby loves taco's!facebook") is just SHA1-sub(SHA1("Tubby loves taco's!face"), "book"). See "length extension attack" for more details. More generally, hash functions are collision-resistant, but t…

That's easily fixable by using an HMAC, as the author should have done in the first place.

Does this attack actually work, by the way? Don't you need to also be lucky with the padding and have the plaintext be an exact multiple of the bytes in the round?

Re: Don't Store Passwords, Generate Them When Needed

#40
post #4

However, this IS a master password only with a salted hash added on top. From the FAQ it uses a phrase like "Tubby loves tacos!facebook" runs it through SHA1 and spits out Facebook's password. Someone who shoulder surfs your keyphrase can now use this technique to generate passwords for any site, whereas using something like Password Safe or the various other password storage methods would need to both shoulder surf…

It's not only been done, "master password with a salted hash" is broken. If I can convince you to log in to face.com ("Tubby loves taco's!face"), I can find the hash of "Tubby loves taco's!facebook". This is because SHA1("Tubby loves taco's!facebook") is just SHA1-sub(SHA1("Tubby loves taco's!face"), "book"). See "length extension attack" for more details. More generally, hash functions are collision-resistant, but t…

[deleted]
Post reply on HN