Everyone here knows Bitcoins - and Bitcoins are very, very secure.
Why not (in offline mode) create a new empty wallet.dat
Move it to removable media.
Sign in on a secure computer to your service provider and upload your newly created empty wallet.dat
When you sign in to a secure service provider the following happens VERY, VERY securely:
They spend a SMALL amount of bitcoins to the shared wallet.dat and request you to spend it back (verifying your identity and shared ownership of the wallet.dat)
With current difficulty and network hash power at ~10THash/sec it should take more than a week to brute force attack with the average PC.
Topic: Public Safety Announcement: On the subject of password security (Read 5880 times)
"how ridiculous is that statement"
"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"
Way to contradict yourself! This discussion is now over.
"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"
Way to contradict yourself! This discussion is now over.
No, you imply that it can't be in a RT because of its "unique salting method", like if two computers would compute a different hash...
However this would be perfectly RT:
crypt("pass","$6$rounds=5000$myeverydaysalt$");
And unknown or per-user salt will prevent RT on every algorithm and not just SHA512
"how ridiculous is that statement"
"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"
Way to contradict yourself! This discussion is now over.
"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"
Way to contradict yourself! This discussion is now over.
If you've any education you would know what Rainbow tables are and how ridiculous is that statement.
Obviously any algorithm can be stored as pre-computed hashes. Your statement is as ridiculous as to say that if I calc the hash under the same parameters at my computer it will render a different result than if I do it at yours. Yes, salt, if unknown or per-user, will prevent Rainbow Tables, but that's valid for any hashing algorithm.
To the end, how breakable it is relies on computing power, what was good at 386's time is an easy picking today, and within 10 years even your SHA512 1000 or 5000 rounds salted with any flavor may be too. But still... for what's in the market now it is nearly unbreakable.
Obviously any algorithm can be stored as pre-computed hashes. Your statement is as ridiculous as to say that if I calc the hash under the same parameters at my computer it will render a different result than if I do it at yours. Yes, salt, if unknown or per-user, will prevent Rainbow Tables, but that's valid for any hashing algorithm.
To the end, how breakable it is relies on computing power, what was good at 386's time is an easy picking today, and within 10 years even your SHA512 1000 or 5000 rounds salted with any flavor may be too. But still... for what's in the market now it is nearly unbreakable.
No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.
You have no reason to refuse to follow industry standards.
You have no reason to refuse to follow industry standards.
So was MD5 10 years ago...
You've a GOOD reason to NOT follow industry standards actually; it's called "Rainbow Tables" and alike.
MD5 was never broken, NTLM was never broken, all of those 1-way hashing mechanisms were never broken, what happened is that they're "industry standards", so it become easy to create dbs with their possible contents.
If you had any education whatsoever in the area of password hashing, you would know that CRYPT_SHA512 is immune to rainbow tables thanks to its unique salt per hash. This is why you should use it instead of plain MD5/SHA1/SHA512 etc.
Thanks, but I respectfully deny credit for this security through obscurity technique. I stated at best this saves 10 bytes but was not robust.
You take this as a dogma, but security IS obscurity. Otherwise there would be no problem into have databases for all sites published in the web.
Data security is to create counter-measures for the principles of information:
WHEN - Information is only valid for a period of time, if someone tips me now that the Nazis have plans to invade Poland it is useless information, as it already happened.
WHERE - Information is only valid at some places. If I get an user/pass db but have no idea from which site it came from, I can do nothing with it.
HOW - What was used to conceal that information. If I can't figure that out within the WHEN buffer I may have useless information in hands. Using "industry standards" or "clear to all security" voids this point, as it's known what was used. The issue may be that a bad cryptographer may create a weak to break code, but variances of known algorithms can help.
No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.
You have no reason to refuse to follow industry standards.
You have no reason to refuse to follow industry standards.
So was MD5 10 years ago...
You've a GOOD reason to NOT follow industry standards actually; it's called "Rainbow Tables" and alike.
MD5 was never broken, NTLM was never broken, all of those 1-way hashing mechanisms were never broken, what happened is that they're "industry standards", so it become easy to create dbs with their possible contents.
Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.
Thanks, but I respectfully deny credit for this security through obscurity technique. I stated at best this saves 10 bytes but was not robust.
No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.
You have no reason to refuse to follow industry standards.
You have no reason to refuse to follow industry standards.
So, mrb, you made a good point for use just MD5 or RipeMD
Basically your statement is: giving enough computing power and every hash can be broken.
Well, MD5 is fast, protects you in case someone had his eyes on the database, and protect the db is the realm and responsibility of the site's owner. Going further to paranoia levels, will just make you to waste electrical power for nothing.
Basically your statement is: giving enough computing power and every hash can be broken.
Well, MD5 is fast, protects you in case someone had his eyes on the database, and protect the db is the realm and responsibility of the site's owner. Going further to paranoia levels, will just make you to waste electrical power for nothing.
Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.
Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.
(Only useful on closed-source projects, tho).
(Only useful on closed-source projects, tho).
If no one knows this is your technique then it is an effective security-through-obscurity measure but if the attacker does know of this technique then an attack table can be compiled even before or while compromising the password list. And what advantage do you have over a salt? saving 10 bytes on disk per user.
Re: the attacker knowing of the technique, that's exactly why I said it would be only useful for closed-source apps.
The main benefit isn't the 10 bytes on disk, but the fact that the salts aren't stored anywhere, so they can't be stolen unless the hacker gets to the source code, in which case the impact of the compromise is more severe than just a user/password database leak.
Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.
(Only useful on closed-source projects, tho).
(Only useful on closed-source projects, tho).
Your suggestion is just adding a simple variation to the hashing algorithm which may prevent an attacker from using an off-the-shelf rainbow table as long as it is a unique idea. If no one knows this is your technique then it is an effective security-through-obscurity measure but if the attacker does know of this technique then an attack table can be compiled even before or while compromising the password list. And what advantage do you have over a salt? saving 10 bytes on disk per user. Sure use a hash of the username as well. I don't think it'll hurt.
This is similar to including a secret into the hash, which is compiled into code (not the password file/database). It's a fine example of security-through-obscurity as it increases the difficult or required attack vectors, but not particularly robust.
@netrin: stretching means iterating the hash function multiple times, eg. 1000 times for Unix MD5()-based crypt.
@an0therlr3: it would lower security to derive a salt from the username only. If an app was doing that and came with a default account (say "admin"), then every user of this app choosing the same admin pw would result in the same hash being generated everywhere.
@an0therlr3: it would lower security to derive a salt from the username only. If an app was doing that and came with a default account (say "admin"), then every user of this app choosing the same admin pw would result in the same hash being generated everywhere.
Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.
(Only useful on closed-source projects, tho).
(Only useful on closed-source projects, tho).
The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems).
This is certainly true, but the salt/nonce can also be thrown out. Known as strengthening or stretching. Now both the server and attacker need to do extra work, just that the server at the time of authentication has much more information, namely the plaintext password.
"Stored per user" doesn't mean "Stored next to password, per user".
It could have been stored on a separate system, in a separate database. Which would have made the leaked passwords worthless without the other "half" of the password file.
It could have been stored on a separate system, in a separate database. Which would have made the leaked passwords worthless without the other "half" of the password file.
This is pointless. This is the same as saying "store the hash on a separate system and make sure it does not get stolen". Hashes (and salts) both get stolen and must be designed to withstand bruteforcing as best as possible.
The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems).
It's not 25 rounds. It's 25 * login length + 25 * password length + 1 iterations. So it's basically few hundrets. Did you measure this code or just 25 rounds of SHA-512?
I stand corrected on the random salt though - it shouldn't derive from username alone.
I stand corrected on the random salt though - it shouldn't derive from username alone.
gmaxwell's point still stands though. A few hundred rounds of SHA512 is not sufficient. This is barely a bit more computationally intensive than MD5-based crypt(), which is not good enough and which is why MtGox and modern Linux distributions are phasing it out.
(Also an undesirable property of your hash function is that the pw/user pair "a:b:c/d" will hash to the same as "a:b/c:d" or "a/b:c:d".)
Use PHP's builtin crypt() CRYPT_SHA512 people! Don't re-invent your own crypto.
PS: I write password bruteforcers.
The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.
Too bad MtGox stored the salt in the password field, next to the password.
Unless you use a single admin-added salt to everyone, you need to store the salt per-user for use different ones to everybody.
Also that is the way crypt returns it:
Code:
$a = crypt("pass","$1$salt$");
echo $a;
Single salt added by config can be brutte-forced if the attacker has a hash for which he knows the password, eg for md5:
Pwd: 12345
$k = 0;
while($result != $hash){
$result = md5("12345",$salts_to_try[$k]);
if($result == $hash) $salt = $salts_to_try[$k];
$k++;
}
"Stored per user" doesn't mean "Stored next to password, per user".
It could have been stored on a separate system, in a separate database. Which would have made the leaked passwords worthless without the other "half" of the password file.
No one is arguing against having per-user salts.
The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.
Too bad MtGox stored the salt in the password field, next to the password.
Unless you use a single admin-added salt to everyone, you need to store the salt per-user for use different ones to everybody.
Also that is the way crypt returns it:
Code:
$a = crypt("pass","$1$salt$");
echo $a;
Single salt added by config can be brutte-forced if the attacker has a hash for which he knows the password, eg for md5:
Pwd: 12345
$k = 0;
while($result != $hash){
$result = md5("12345",$salts_to_try[$k]);
if($result == $hash) $salt = $salts_to_try[$k];
$k++;
}
Jump to: