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

Speed Hashing

codinghorror.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Speed Hashing

#101

Post by tptacek »

aidenn0 wrote: post #97
cperciva wrote: post #36

Using "hash" to mean "strongly collision-free function" is a valid terminological choice; in a wide-readership piece like this it should ideally be pointed out in order to avoid confusion, but there are many fields where that definition would be assumed without statement. Getting confused between hash functions and password-based key derivation functions , on the other hand, is absolutely inexcusable; that very confu…

Also PBKDF2 is not designed to be hard to crack on a GPU. PBKDF2 is actually notoriously easy to implement on a GPU or FPGA due to its small fixed amount of ram. It's probably not a huge deal since taking a large fraction of a second on a CPU to validate a login would translate into taking a large fraction of 1/150 of a second per password crack attempt on a GPU so it still is decent security. For something designed…

A bigger reason PBKDF2 is easy to implement on GPUs is that it's (almost always) built out of primitives that are already widely available in GPU implementations, like SHA1 and SHA256.

That's why I recommend PBKDF2 with the PRF set to the authentication tag from FEAL4 in GCM mode. Nobody's got that in a GPU! Arrrrr!

Re: Speed Hashing

#102

Post by tptacek »

revelation wrote: post #92

Here is my problem with all of this. PBKDF really just means "take this hash function and apply it 1000 times in succession". That seems like a very butchery style to approach cryptography for me. bcrypt seems to lack any research verification. Its a modified blowfish, but who of us can tell what modifications are safe without making the scheme ineffective and gauge its validity?

PBKDF2 is more complicated than just iterating a hash 1000 times, but for most applications, iterating SHA1 many thousands of times is just fine.

I'm not sure what kind of research verification you're hoping to get for a password hash. These aren't the kinds of constructions where the possibility of spending 48 hours of cluster compute time to generate a collision will actually hurt you.

Sometimes, "research verification" is just a fig leaf for "too many Rails developers got uppity about using bcrypt and now I need to signal that I'm not one of them". Password hashes don't get a lot of research attention because they're pretty basic, cryptographically speaking.

Re: Speed Hashing

#103

Post by cperciva »

tptacek wrote: post #99
cperciva wrote: post #87

Earlier quoted context omitted.

I don't see that it was repurposed; "key derivation function" != "encryption key derivation function", and I prefer the term "login key" over "password hash".

Since there are good password hashes that are also bad KDFs, I'm not sure I agree with the equivalence.

There are?

Re: Speed Hashing

#104

Post by derefr »

codinghorror wrote: post #19
judofyr wrote: post #9

Nitpicks. It seems that he's talking about password hashing: > "Hashes are designed to be tamper-proof". Wrong. Cryptographically secure hash functions are. > "Hashes, when used for security, need to be slow." Wrong. Password hashes needs this; not SHA1/MD5 etc.

Well, I'd say a hash that has no need whatsoever to be tamper-proof (no attackers, ever) and cares only about speed is a checksum -- so maybe a terminology issue. I agree there are certainly other uses for hashes, just trying to distinguish between hashes and checksums. Re-reading what I wrote, I open with "Hashes are a bit like fingerprints for data. A given hash uniquely represents a file, or any arbitrary collecti…

> Well, I'd say a hash that has no need whatsoever to be tamper-proof (no attackers, ever) and cares only about speed is a checksum -- so maybe a terminology issue.

Imagine someone trying to attack a BitTorrent tracker by injecting false data packets with "true" hashes. This is a case where you do want the properties of a hash, not a checksum (changing a single bit greatly changes the output; it's hard to figure out an input that will create a matching output) but you don't want the properties of a cryptographically-secure hash (slow to calculate.)

Re: Speed Hashing

#105

Post by charlieok »

I think it's also worth looking at the protocol used to perform the authentication. This is closely tied to what kind of verifier you can/can't store.

If you store a salted hashed password, the authenticating party needs to send you the actual password.

Sure, they could send you the password over an encrypted connection. But that implies that a security context (and shared secret) has already been established. There's a chicken/egg problem here. The most desirable approach is to use a protocol which performs mutual authentication as part of the initial setup of the security context.

There are protocols which can perform password-based authentication without actually sending the plaintext password. It's called a zero-knowledge password proof. In addition, some of these allow a "verifier" to be stored rather than the password itself.

In this scenario, not only do you not store a secret which would allow impersonation of a user, but that secret is also never even sent to you.

We need support for this in browsers :)

Re: Speed Hashing

#106

Post by [deleted] »

mojuba wrote: post #38

And to slightly improve salting: $pw_hash = sprintf('%s|%s|%s|%s|%s', SALT1, $user_name, SALT2, $pw, SALT3); In fact, my salts usually include non-printables, including the NULL char, plus they are very long.

[deleted]

Re: Speed Hashing

#107

Post by ajross »

ajross wrote: post #88
tptacek wrote: post #80

Earlier quoted context omitted.

"Password based key derivation function". The problem here isn't that cryptographers are inflicting a terrible name at you, it's that security people have repurposed a function intended for one purpose (generating crypto keys) for another (storing passwords). Also: don't blame us, blame the PKCS standards group.

Sure sure. What I'm really saying is that the core concepts here are "collision resistance" and "susceptibility to brute force", and that those are comparatively easy to grok for a typical developer. But they get scared to death when they read stuff like (verbatim from cperciva above) "MD5's breakage as a hash function does not impact its security as a PBKDF, and not realizing that MD5 and SHA256, being not designed…

To clarify: the clear English way to write that would be something like "Colliding passwords aren't a problem, because it's cheaper to search the password space anyway, so you can use MD5 there securely. But MD5 and SHA256 were designed to be cheap to compute, so they're easy to brute force. Use a password function designed to be expensive instead." Charging off down the jargon road can only complicate things. And doing so in a post about people being confused (!) about the subject is frankly hurting, not helping.

Re: Speed Hashing

#108

Post by [deleted] »

eruquen wrote: post #94
tptacek wrote: post #79

Earlier quoted context omitted.

That's because it's a silly idea which is inferior to cryptographic adaptive hashing, as is done by bcrypt, scrypt, and PBKDF2. If you want to provide a work factor, use a real one.

First of all, you come off as condescending when you say "it's a silly idea" and say that the work factors you mentioned are "real" ones, thereby implying that adding more combinations is not a real work factor. Second, the actual usefulness of any work factor has to be proven first. Do we know that the iterative approaches offer "real" work factors? What if subsequent iterations are easier to compute by exploiting t…

[deleted]

Re: Speed Hashing

#109

Post by judofyr »

donpark wrote: post #62
judofyr wrote: post #59

Earlier quoted context omitted.

> What's the point of salt if salt is in plain sight? If you by "plain sight" mean "the same place as the hash" you're misunderstanding what the salt is for. If you want to access X servers in order to verify a password, you don't need a salt; you just split the hash in X parts and store each on different servers. Salts are for preventing rainbow tables.

It doesn't matter if the hash is split into X parts and stored on X servers. We are not talking about Humpty Dumpty here and salt-specific rainbow tables can be built on-demand as long as the reward justifies the time and expense.

> rainbow tables can be built on-demand

That's what we call bruteforce…

Re: Speed Hashing

#110

Post by donpark »

dpark wrote: post #76
donpark wrote: post #53

Where to store the salt is that's where the real problem is. It doesn't really matter how much encryption and hashing we throw at anything if everything is stored on the same server. What's the point of salt if salt is in plain sight? What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself? What's the point of cryptography when code points straight to all t…

> What's the point of salt if salt is in plain sight? To prevent rainbow tables and to increase attack complexity. And to prevent someone who sees a hash from being able to drop it into a search engine and get the password (works for unsalted common passwords). The point of salt has never been secrecy. > What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itse…

Your answers make sense in the context of servers for websites with low security needs, where privacy is of higher concern than security.

They do not make sense for servers with high security needs.

Post reply on HN