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

Show HN: A simple “stateless” password manager for Chrome

stephanboyer.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Show HN: A simple “stateless” password manager for Chrome

#31

Post by desdiv »

jackjeff wrote: post #25

It needs to be improved to be secure - salt. To avoid rainbow table attacks. One could use the login/email as salt - key strengthening function. Instead of repeating naively SHA-256 a few times, use PBDKF2 or even better, something which is also memory hard like scrypt. Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think abo…

>Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.

It would be great if there was a site ran by a widely-trusted body (EFF for example) that tracks the various password requirements and limitations of websites. That way password managers, such as this one, can query that authoritative database for the idiosyncratic password rules for each domain and generate a password of the maximum allowable length and with the largest possible alphabet.

Re: Show HN: A simple “stateless” password manager for Chrome

#32

Post by stepstep »

SwellJoe wrote: post #3

I've been using SuperGenPass for this for years. There is a Chrome extension that is safe (from website snooping of your key) and a browser bookmarklet that is not safe. But, I just use the mobile browser version in another tab and copy paste since I choose to use Firefox. It's a little less convenient, but not inconvenient enough that I've spent time trying to figure out how to make a safe extension for Firefox. So,…

Just took a look at the SGP FAQ and saw this:

> SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate passwords. Specifically, it concatenates the master password and the domain name of the Web site (masterpassword:domain.com), hashes the result at least ten times (and until it satisfies the generated password requirements), and cuts the result to the desired length.

Yikes! MD5 is known to be broken, and 10 rounds of hashing is no defense against brute force attacks. Hashpass uses SHA-256 (not broken) and does 2^16 rounds of hashing.

Re: Show HN: A simple “stateless” password manager for Chrome

#33

Post by stepstep »

moe wrote: post #26
stepstep wrote: post #20

Earlier quoted context omitted.

Stanford published a paper that is basically the exact same model: http://crypto.stanford.edu/PwdHash/pwdhash.pdf This is not a new technique. In addition to the Stanford paper, there are several other implementations mentioned in these comments. It's a compromise, not a mistake. It is better to memorize one strong password than a dozen weak ones. This isn't custom crypto. It's a well-known hash function that serves…

Stanford published a paper that is basically the exact same model Um yea.. "basically". Except they demand an 'ultra-slow' hash function in that paper. You ignored that requirement and that makes your implementation equivalent[1] to using the same password for all websites. [1] https://www.achilleslabs.com/product/4

2^16 rounds of SHA-256 might not be "ultra slow" but it's certainly not as bad as you make it seem. If you read the analysis in the article, it would take many years to crack a random password with this hash function. It's unfair to say I "ignored" that requirement.

Re: Show HN: A simple “stateless” password manager for Chrome

#34

Post by stepstep »

ansible wrote: post #30
stepstep wrote: post #13

Earlier quoted context omitted.

I tried to address this in the article: "If a generated password is ever compromised, you don’t need to memorize a whole new secret key and update all of your passwords. For that service only, just add an incrementing index to your secret key. For example, if your key was bananas, just use bananas2. If you can’t remember which iteration of your secret key you used for a particular service, simply try them all in orde…

And that then starts to negate the point of this password manager: having to remember just one password.

You don't have to memorize them, though. If your master key is "bananas" and it didn't work, try "bananas2", "bananas3", etc. But you don't need to remember them all—because they're all essentially the same.

Hopefully this happens infrequently enough that it's a non-issue anyway.

Re: Show HN: A simple “stateless” password manager for Chrome

#35

Post by moe »

stepstep wrote: post #33
moe wrote: post #26

Earlier quoted context omitted.

Stanford published a paper that is basically the exact same model Um yea.. "basically". Except they demand an 'ultra-slow' hash function in that paper. You ignored that requirement and that makes your implementation equivalent[1] to using the same password for all websites. [1] https://www.achilleslabs.com/product/4

2^16 rounds of SHA-256 might not be "ultra slow" but it's certainly not as bad as you make it seem. If you read the analysis in the article, it would take many years to crack a random password with this hash function. It's unfair to say I "ignored" that requirement.

If you read the analysis in the article, it would take many years to crack a random password with this hash function.

You are wrong. Your analysis is based on the premise that an attacker might be able to compute "a billion hashes per second".

As I just showed you in my previous comment anyone with $3000 USD can actually compute at least 6000 billion hashes per second.

This means it takes about 11 days to crack a random 8-character alphanumeric password. Not 200 years as you claim.

Re: Show HN: A simple “stateless” password manager for Chrome

#36

Post by baruch »

ansible wrote: post #30
stepstep wrote: post #13

Earlier quoted context omitted.

I tried to address this in the article: "If a generated password is ever compromised, you don’t need to memorize a whole new secret key and update all of your passwords. For that service only, just add an incrementing index to your secret key. For example, if your key was bananas, just use bananas2. If you can’t remember which iteration of your secret key you used for a particular service, simply try them all in orde…

And that then starts to negate the point of this password manager: having to remember just one password.

I use a similar tool (pwdhash) and the benefit is not that it's a single password but a single root password. I need only a few changes and very little to remember for most sites and still get a unique password per site.

My bank requires me to change the password every 3 months or so and I only need to change on digit in what I remember and they see a whole new password.

It's a great benefit to me and to overall security.

How secure is it overall? Somewhat more secure than just using a single password for all sites and better trust compared to using a cloud based password storage.

Re: Show HN: A simple “stateless” password manager for Chrome

#37

Post by marijn »

[deleted] wrote: post #22
anton_gogolev wrote: post #4

Why do 2^16 rounds of a designed-to-be-fast SHA-256 when there are deliberately slow PBKDF, such as scrypt?

[deleted]

If you really have to, you can use a static salt -- this is no reason not to use a designed-to-be-expensive hash function.

Re: Show HN: A simple “stateless” password manager for Chrome

#38

Post by moe »

stepstep wrote: post #32
SwellJoe wrote: post #3

I've been using SuperGenPass for this for years. There is a Chrome extension that is safe (from website snooping of your key) and a browser bookmarklet that is not safe. But, I just use the mobile browser version in another tab and copy paste since I choose to use Firefox. It's a little less convenient, but not inconvenient enough that I've spent time trying to figure out how to make a safe extension for Firefox. So,…

Just took a look at the SGP FAQ and saw this: > SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate passwords. Specifically, it concatenates the master password and the domain name of the Web site (masterpassword:domain.com), hashes the result at least ten times (and until it satisfies the generated password requirements), and cuts the result to the desired length. Yikes! MD5 is known to be broken, a…

No, SHA-256, the way you use it, is not "far too slow for brute-force".

To anyone reading here: Please do yourselves a favor and stay away from BOTH SuperGenPass and from this one.

They are nearly equivalent to using the same password for every website. A malicious website owner can derive your "master password" from the hash that you gave them and thereby gain access to all your websites.

Re: Show HN: A simple “stateless” password manager for Chrome

#39

Post by [deleted] »

a1a wrote: post #9

Please tell me I am missing something. There is no salt. The hashing algorithm is hence vulnerable to a simple dictionary attack. It does not matter if you do a gigazillion rounds. Someone can still pre-calculate a list of common passwords and then test that list against each and every user.

[deleted]

Re: Show HN: A simple “stateless” password manager for Chrome

#40

Post by [deleted] »

stepstep wrote: post #16
a1a wrote: post #9

Please tell me I am missing something. There is no salt. The hashing algorithm is hence vulnerable to a simple dictionary attack. It does not matter if you do a gigazillion rounds. Someone can still pre-calculate a list of common passwords and then test that list against each and every user.

Correct, there is no salt. A dictionary attack will uncover common passwords. It's crucial to pick a strong secret key. That's the price you pay for using a stateless password manager. However, the gigazillion rounds are not for nothing. That is the defense against brute force attacks, which could otherwise crack passwords even if they are random.

[deleted]
Post reply on HN