Password security quick basics:
Developers -> use bcrypt
Users -> use a service like Lastpass with a long passphrase as master password; use unique 12+ character (including specials!) passwords through Lastpass
Speed Hashing
21–30 of 133 posts
Re: Speed Hashing
#22While long and random passwords are a good thing, there are still applications that make that very difficult to use.
I'm looking at you, Apple AppStore, letting me choose a new password after only the second wrongly-entered, disallowing copy&paste on that website to enter the new password, requiring JavaScript on that website to enforce the no-copy&paste rule and then not showing me the characters I enter.
That's ridiculous. After the fifth attempt to enter my 20-character password correctly (which was chosen randomly by my Password manager), I gave up and entered a 8-character password.
So the problem is not only the user, but also ridiculous application requirements.
Re: Speed Hashing
#23"salts alone can no longer save you"
I use two salts to hash a password: sha1(SALT . SALT2 . $password); the second salt is unique for every user and stored in a database. Why is it not secure?
Re: Speed Hashing
#24Nitpicks. 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…
I am afraid the terminology you use is not canonical.
A hash (function) is any function that maps a big variable-length data structure to a smaller (fixed-length) data structure.
A checksum is a special hash (function) which has the purpose of detecting accidental errors during transmission or storage. (This makes them different from hash functions used for example in hash tables. For example relevant question: minimum how many badly transmitted bits are needed to break the error detection in the case of a specific checksum?)
A cryptographic hash function is another kind of special hash function which also has a very good definition on wikipedia.
(Basically these are the definitions on Wikipedia, and I think they are fine. If the terminology you use would be canonical we would use the name 'checksum table' instead of 'hash table', and it would be quite illogical also, because the term 'checksum' really includes purpose in its name 'checking something').
Re: Speed Hashing
#25Earlier quoted context omitted.
As often, he plays fast and loose with terminology and uses "checksums" for "hash functions" and "hashes" for " cryptographic hash functions". > the hashes used in SSL and the like are designed to be as fast as possible without sacrificing too much security. See also: map and set hashes. There, you're looking for speed and good distribution across the buckets, a slower hash function is not something to look forward t…
I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? MD5 is clearly just a checksum now, since it's not secure, but it was designed to be originally. And would you ever want to use a checksum that others could manipulate at will? Curious. I feel like the line between "this is a checksum" and "this is a secure hash" is kind of illusory, other than for…
> I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file?
Sufficient. all hashes (cryptographically secure or not) will fail to detect some changes, that's a hash collision and that's an intrinsic and non-negotiable property of m:n mappings where len(m) > len(n). "Checksums" assume there is no attack being performed, as in nobody is trying to craft a collision. In "normal operations", even with pretty shitty hash functions (e.g. CRCs) hash collisions between subsequent file changes (or whatevere) are unlikely enough.
Re: Speed Hashing
#26Nitpicks. 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…
Secure hashes need to be fast. If you look at the ongoing SHA-3 competition, you will see an enormous focus on speed, on both software and hardware.
Why do they need to be fast? They're used everywhere. Opening up notepad.exe, you'll verify a handful of digital signatures, each of which will compute a hash of the binary as first order of business. HMAC is used in virtually every secure network protocol worth using --- it uses an underlying hash as building block. Need a fast (determistic) pseudorandom generator? Hashes it is.
Password hashing (and key derivation) is about the single use of hashes that requires computational hardness. It should be treated separately.
Re: Speed Hashing
#27"salts alone can no longer save you" I use two salts to hash a password: sha1(SALT . SALT2 . $password); the second salt is unique for every user and stored in a database. Why is it not secure?
Because it's stored in a database. If an attacker has access to the database with the hashed passwords she will likely have access to the database with the salt too.
Re: Speed Hashing
#28"salts alone can no longer save you" I use two salts to hash a password: sha1(SALT . SALT2 . $password); the second salt is unique for every user and stored in a database. Why is it not secure?
Because it's stored in a database. If an attacker has access to the database with the hashed passwords she will likely have access to the database with the salt too.
but only the second salt is stored in a database, the first salt is stored under WWW-Root.
Re: Speed Hashing
#29Earlier quoted context omitted.
Because it's stored in a database. If an attacker has access to the database with the hashed passwords she will likely have access to the database with the salt too.
but only the second salt is stored in a database, the first salt is stored under WWW-Root.
It's still there on the server, if the attacker has her hands on the database you have to assume that the entire server might be compromised
Re: Speed Hashing
#30Earlier quoted context omitted.
E.g. ZFS uses non-cryptographical hashes to detect bitrot. TCP and IPv4 use a non-cryptographical hash to detect packet corruption. Etc.
terminology issue, I guess, I'd call those checksums -- where speed is the overriding concern and you're not worried about attackers changing the data underneath you. (And you actually need to uniquely identify the data in a reliable way..)
Sure, it's a terminology issue, but as several others have pointed out, you're the only one using your terminology. So expect people to be confused when you try to explain these things using your definitions.