Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Store Passwords, Generate Them When Needed

16s.us

Post reply on HN
Print view View original

41–50 of 64 posts

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

#41

Post by frobozz »

I use passwordcard (http://www.passwordcard.org/en) as my password manager,

1) All my passwords are stored on a piece of paper, in plain text. There is no need to encrypt, because only I know how I use it.

2) I don't need to back it up regularly. Just one backup, in case I lose the card, is enough.

3) Because I have to type in the passwords from it, I actually remember the ones I use regularly, so even if I lose the cards, I can log in to most things.

4) There is no "master password" to be exposed.

5) If I'm stupid enough to read it out loud, or run my finger along it whilst someone is watching, I might expose the parameters of one password, but everything else is still secure.

6) It is a piece of paper, the browser integration goes via my eyes and my fingers.

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

#42

Post by strayer »

IsaacL wrote: 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…

> I don't like the idea of using a password manager, because it's difficult to move it across platforms

http://clipperz.com is a very portable password manager.

It works on your computer as well as online.

It relies on your browser being a "secure" Javascript interpreter. But then we do that every time we log into a web site.

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

#43

Post by strayer »

http://clipperz.com rocks in terms of usability, convenience, and a sense of security (which might be false: here is a call for criticism).

It is open source, portable (runs in Javascript), works on and offline and well designed. You can log in using a master passphrase, or a one-time password.

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

#44

Post by JoachimSchipper »

StavrosK wrote: post #39
JoachimSchipper wrote: post #37

Earlier quoted context omitted.

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?

Yes, HMAC is (one of) the right solution(s) here. On the other hand, do you trust the rest of the program if the author gets this wrong?

The attack does work, see e.g. http://www.vnsecurity.net/t/length-extension-attack/. This example suggests that any padding should not matter; and even if it does, being able to mount this attack on a substantial part of visitors is bad. (Sorry for being vague here - I don't have the time to look at this properly now.)

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

#45

Post by [deleted] »

JoachimSchipper wrote: post #37
biot wrote: 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]

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

#46

Post by [deleted] »

[deleted] wrote: post #45
JoachimSchipper wrote: post #37

Earlier quoted context omitted.

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]

[deleted]

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

#47

Post by Tharkun »

JoachimSchipper wrote: post #37
biot wrote: 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…

What you point out here is a very implausible attack to perform. Not only would you need to know that the user is using this scheme to generate a password, you would also have to know how he generates the salt (maybe they use fb, or FACEBOOK or facebook.com). But then you'd have to be able to trick him into signing into some website with a name that's a subset of the aforementioned salt. Hell, even using FQDNs would fix the "problem" in most cases.

For the average user, a scheme like this would be a vast improvement over their "123456 is secure enough, no?"-scheme.

Putting the face/facebook start at the front of the passpphrase string would fix that. So would an HMAC.

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

#48

Post by loup-vaillant »

frobozz wrote: post #41

I use passwordcard ( http://www.passwordcard.org/en ) as my password manager, 1) All my passwords are stored on a piece of paper, in plain text. There is no need to encrypt, because only I know how I use it. 2) I don't need to back it up regularly. Just one backup, in case I lose the card, is enough. 3) Because I have to type in the passwords from it, I actually remember the ones I use regularly, so even if I lose th…

Variation on that theme: http://blog.jgc.org/2010/12/write-your-passwords-down.html

I did an implementation of it (http://www.loup-vaillant.fr/projects/password-generator)

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

#49

Post by JoachimSchipper »

Tharkun wrote: post #47
JoachimSchipper wrote: post #37

Earlier quoted context omitted.

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…

What you point out here is a very implausible attack to perform. Not only would you need to know that the user is using this scheme to generate a password, you would also have to know how he generates the salt (maybe they use fb, or FACEBOOK or facebook.com). But then you'd have to be able to trick him into signing into some website with a name that's a subset of the aforementioned salt. Hell, even using FQDNs would…

Reversing the order is not a good idea: read http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-has... for a readable introduction (summary: it works, but it maximally exposes you to any possible problems.) Just use HMAC, especially if you want to use SHA1 - which is not broken, but no longer above suspicion.

I agree that this scheme is probably fine as long as you're the only one using it and nobody is specifically targeting you; but if you're going to go to use a password manager (which would be an improvement in general - as you point out, "123456 is secure enough, no?" is prevalent), why not use a good password manager?

Post reply on HN