3 ms·

That may look sane, but you're deriving all your passwords from a single master "key". Leak it once, for any reason, and all your passwords just became known. (

by bostik 12y ago

That may look sane, but you're deriving all your passwords from a single master "key". Leak it once, for any reason, and all your passwords just became known. (Unless you provide unique value of 'n' for each site, which I doubt you do.) If you use a common login or email address as your user name across the sites you use, they all pop open at the same time. My take on password generation is even more straightforward: % head -c 9 /dev/urandom | base64 Then whatever comes out, I store on an encrypted volume - so effectively I do have a master passphrase but none of the login credentials are derived from it. For sites that I think require even more entropy, I'll just bump up the number of bytes read. (98 = 72 bits of entropy, 128 = 96 bits) I haven't yet found a password manager I truly liked. EDIT: you do realise you are capping the entropy of your per-site passwords at 72 bits? It's more than enough against all practical brute force attacks, but it also means that any entropy in your master key above 72 bits is effectively lost.

deleted 12y ago
[deleted]
dheera 12y ago
I don't store my master password anywhere or execute this generator on a device that I don't own. The main problem with fully random passwords is that I need to carry my encrypted volume around with me everywhere, and also worry about backing it up. Yeah I realize it is being capped at 72 bits -- the main reason is that I've seen a bunch of websites that don't allow passwords longer than 18-20 characters or so. :-/
svenfaw 12y ago
>more than enough against all practical brute force attacks Source?
- bostik 12y ago
  Math. But to give some substance to the claim, the speed record for single-system password hashing in 2012 was ~350GH/s [0]. Let's assume that in 2015 a single system is capable of doing 1TH/s, or ~1000GH/s. So, 10^12 password attempts per second. An attacker, who is not a nation state, should be expected to have access to maybe 400 such systems. But to make this conservative, let's assume they have 1000 such systems. So, the attackers should be able to reach 1000 TH/s, or 10^15 attempts per second. 10^15 =~ 2^(15/0.301) =~ 2^50. Hence, a determined attacker with finite resources has to do, on average, 2^31 seconds of work to brute force a password with 72 bits of entropy. 2^31 seconds is roughly 68 years. That in turn means that there are lot of lower hanging fruit to pick before even thinking of expending resources to brute force passwords with 72 bits of entropy. On the other hand, the resource requirements are getting awfully close to the realm of feasibility, so 72 bits might not be sufficient for long after all... 0: http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billion-hashes-per-second-to-crack-your-passwords/ http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billi...
  - dheera 12y ago
    I feel like it wouldn't be anywhere close to 10^15 if they use a slow hashing algorithm, which is what password stores should be using (e.g. http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 )
    - bostik 12y ago
      Indeed :) Every new sensible implementation of password store is using either bcrypt, pbkdf2 or scrypt. I picked the lowest common denominator because it caters for the worst case scenario. Systems where passwords are improperly hashed are quite likely to have other security problems too. And as such are more likely to get breached, whereby their password store is lifted too.
  - bostik 12y ago
    Bah, that's embarrassing. I will break the HN etiquette and reply to myself, because I will not succumb to editing the post above and retroactively fix a calculation error. Whatever comes from that, I deserve it. I was off by 2^10. For some reason I kept thinking the 72 bits as 82 bits. You can even see that from the numbers! So yes, 72 bits is not enough anymore. I stand corrected. New ballpark figure for sensible security margin should be 96 bits.

by bostik 12y ago

deleted 12y ago

[deleted]

dheera 12y ago

I don't store my master password anywhere or execute this generator on a device that I don't own. The main problem with fully random passwords is that I need to carry my encrypted volume around with me everywhere, and also worry about backing it up. Yeah I realize it is being capped at 72 bits -- the main reason is that I've seen a bunch of websites that don't allow passwords longer than 18-20 characters or so. :-/

svenfaw 12y ago

>more than enough against all practical brute force attacks Source?

bostik 12y ago
Math. But to give some substance to the claim, the speed record for single-system password hashing in 2012 was ~350GH/s [0]. Let's assume that in 2015 a single system is capable of doing 1TH/s, or ~1000GH/s. So, 10^12 password attempts per second. An attacker, who is not a nation state, should be expected to have access to maybe 400 such systems. But to make this conservative, let's assume they have 1000 such systems. So, the attackers should be able to reach 1000 TH/s, or 10^15 attempts per second. 10^15 =~ 2^(15/0.301) =~ 2^50. Hence, a determined attacker with finite resources has to do, on average, 2^31 seconds of work to brute force a password with 72 bits of entropy. 2^31 seconds is roughly 68 years. That in turn means that there are lot of lower hanging fruit to pick before even thinking of expending resources to brute force passwords with 72 bits of entropy. On the other hand, the resource requirements are getting awfully close to the realm of feasibility, so 72 bits might not be sufficient for long after all... 0: http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billion-hashes-per-second-to-crack-your-passwords/ http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billi...
- dheera 12y ago
  I feel like it wouldn't be anywhere close to 10^15 if they use a slow hashing algorithm, which is what password stores should be using (e.g. http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 )
  - bostik 12y ago
    Indeed :) Every new sensible implementation of password store is using either bcrypt, pbkdf2 or scrypt. I picked the lowest common denominator because it caters for the worst case scenario. Systems where passwords are improperly hashed are quite likely to have other security problems too. And as such are more likely to get breached, whereby their password store is lifted too.
- bostik 12y ago
  Bah, that's embarrassing. I will break the HN etiquette and reply to myself, because I will not succumb to editing the post above and retroactively fix a calculation error. Whatever comes from that, I deserve it. I was off by 2^10. For some reason I kept thinking the 72 bits as 82 bits. You can even see that from the numbers! So yes, 72 bits is not enough anymore. I stand corrected. New ballpark figure for sensible security margin should be 96 bits.