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

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

111–120 of 215 posts

Re: How To Safely Store A Password

#111

Post by praptak »

icebraining wrote: post #109
praptak wrote: post #90

You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.

If you leave out bits, any password whose hash matches the rest will work, even if it doesn't match the 'lost bits' (since your login server won't be able to verify that, obviously). The only thing you've accomplished is to make the cracker's life easier.

You don't leave out bits from the hash but from the salt. The hash is stored whole and (obviously) needs to match whole.

Re: How To Safely Store A Password

#112

Post by 16s »

It's good to raise awareness of this issue. When more devs began using bcrypt or scrypt, offline password cracking will be much, much more difficult.

The only reason GPUs are cited as testing 600 million hashes a second is that the underlying hashes came from a Microsoft Windows Active Directory where they were simply MD4 encoded. That speed is not possible with bcrypt. Devs need to understand this.

Edit: Yes, that's MD4 not MD5. Microsoft Windows NT hashes are simply Unicode strings that are MD4'ed. This includes Windows 7 and Windows 2008 server.

Re: How To Safely Store A Password

#113

Post by praptak »

dchest wrote: post #91
praptak wrote: post #90

You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.

You can also write a new cipher, discover a new key derivation function, and invent a new hash function. But that's not the point. Use bcrypt or scrypt.

Any analogy between using a standard technique with a standard hash and going for DYI cryptography is a bit stretched.

Re: How To Safely Store A Password

#114

Post by lamby »

brown9-2 wrote: post #102
klon wrote: post #71

Does anyone know how Djangos built-in password hashing fares?

Looks like the built in stuff uses either sha1, md5, or crypt: https://docs.djangoproject.com/en/dev/topics/auth/

http://code.playfire.com/django-bcrypt/ Backwords-compatible bcrypt support.

Re: How To Safely Store A Password

#115

Post by chalst »

swombat wrote: post #87
ihodes wrote: post #57

Earlier quoted context omitted.

What do you do when you loose the keys? You don't. And ideally you have a single key. If you can be trusted to keep a social security card and a passport, you can just as easily keep a key safe. Print it out. Store it in a safe place. We've been doing that for centuries. And the default behavior or enabling keys whenever your computer is open? You can password protect your keys.

Passports and social security cards are physical items. Because of this, they have the inherent property of not being capable of ubiquity. If someone steals your passport, you'll know: you won't be able to find it. Digital keys have no such properties. If someone steals your private key, you will have no idea until you see them steal all your money and accounts. Physical items also need to be carried to a destination…

I think we have to distinguish between stealing and cloning here. If someone steals the scrap of paper you wrote your key on, then you will know. And passports do get cloned; the issue is convenience.

1. http://www.independent.co.uk/news/uk/home-news/clone-wars-mo...

2. http://www.expatsvoice.org/forum/showthread.php?t=7001

I guess that Mossad can gather the information needed to clone a passport in under half a minute.

So while I agree that the analogy between key reminder and password is not perfect, the point is basically sound.

(On rereading your post, your point [p]hysical items also need to be carried to a destination to be used made me realise that I might have misunderstood the point you were making, but also that you may have misunderstood the point ihodes was making).

Re: How To Safely Store A Password

#116

Post by roel_v »

InclinedPlane wrote: post #33
tzs wrote: post #28

I'd like to see sites offer the option of not using password-based authentication. Instead I'd like to see public key based authentication as an option. Basically, the site would have a copy of my public key (say my GPG key or an ssh key), and to authenticate I prove that I have access to the corresponding private key.

With smartphones this is increasingly feasible. Lots of sites already use smartphone based two factor authentication (similar to rsa keys). There's no reason why a challenge / response system couldn't be set up using smartphones. For example, a website gives you a string of numbers, you input those in your smartphone app and get the response which yiu then input back to the site, the site can't determine the response…

This is how blizzard (World of Warcraft) authenticators work. It's quite ironic how an online game has strong security mechanisms, yet many tools that people use just as often or more (gmail, facebook, pretty much all SaaS tools, including business) and that are are certainly more 'important' (in an objective sense, I understand that people are more attached to their WoW character than to their customer database) don't.

Re: How To Safely Store A Password

#117

Post by Tichy »

brown9-2 wrote: post #103
Tichy wrote: post #81

So I assume if you use bcrypt, you only verify the password once upon login, and then store a cookie that verifies the user is logged in? That brings other security risks. But the alternative seems to be to make every request very slow, because it would require bcrypting the password with every request.

If you were to re-authenticate the user on every request, how do you have the client send the password to the server on every request without making the user enter it every time?

By storing it in a cookie - oh :-)

I suppose you could come up with some scheme where you create a new cookie with every request, a kind of one-time cookie to prevent session hijacking. Probably not worth it and not 100% reliable, though.

I guess just trusting in cookies is the only real option.

Or HTTP BasicAuth, it sends the password with every request I think (unencrypted, I know). In either case in theory you need HTTPS.

Re: How To Safely Store A Password

#118

Post by roel_v »

icebraining wrote: post #106
rubinelli wrote: post #98

Earlier quoted context omitted.

The Brazilian government has been trying to popularize digital certificates stored in smart cards and tamper-proof USB tokens that seem to be a solution to the problems you pointed at. The main barrier to adoption right now is cost, mainly because certificate issuers have little competition and a good chunk of money between infrastructure and concession fees to recoup.

Here in Portugal our new national ID cards all have a public/private key pair and the card itself can sign stuff without copying the private key to the machine, making the process very safe even when using it on a public machine. In a couple of years everyone will have on of those cards, the problem is that nobody has readers.

Here in Belgium we have the same cards, and the readers are cheap. The reason they will be wide-spread is because you can use them to file your taxes online, which many people are starting to prefer over the paper version. I think it's a good incentive for people to start buying these things. I just hope they will become standard on computers soon, but I fear not because the dominant markets (US, really) don't have such systems.

Re: How To Safely Store A Password

#119

Post by roel_v »

podperson wrote: post #17
chops wrote: post #10

Earlier quoted context omitted.

The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.

It's a hash function and, at least over an insecure connection, you should not be transferring the plaintext password from client to server so it's not guaranteed that you will have the plaintext password. Assuming you're using a secure connection and you're willing to send plaintext passwords over it then yes, you could re-hash the password when a user logs in.

It's rather obvious that we're talking about a system in which the client submits the clear-text password to the server, and of course that should be done over SSL.

Re: How To Safely Store A Password

#120

Post by roel_v »

TwistedWave wrote: post #96
Smerity wrote: post #35

Earlier quoted context omitted.

One possible option is challenge-response authentication. There a number of variations, but the simplest example is to hash both the hashed password and a nonce on both ends and check the resulting hash[1]. This means that the server only requires that the hashed password is stored, and the client never sends the password in plaintext as it generates the hash itself. As long as the nonce is unique each time, we can p…

The goal of hashing the passwords is to not store them in plaintext in the database, in case the server is compromised. In your case, an attacker doesn't need the password, the hash is enough to login.

I suppose you mean "goal is to not store them in plaintext"? I was confused there for a second.
Post reply on HN