Password transformation for crypto app
-
From a cryptographic view, the security chain is only as strong as the weakest link, and that is the password/passphrase typed in by the user. So, if you think that's strong and secure enought, take it. Everything else is just some additional voodoo/obfuscation, but adds no security!
-
Ok thank you.
And for the hash rounds. Is 3 or 4 enough, or do I have to increase it to 1000 or 2000 ?
Some other crypto app does it, but I don't know if it's more secure or not... :/ -
Sorry, I'm not that deep into cryptography. Just some general advice:
I think you should read some good introduction into cryptography and security before you go on. Maybe some specialized forum or newsgroup can help you too. Cryptography is a delicate topic and, unfortunately, if you do it wrong you'll do more harm than help. So always check the advices twice before you take your decision.
-
No problem.
I not going on it without reading first ;)
Recently I've changed my "identity" writing process, I've removed any "verification" data.So now, (for example) if you try to bruteforce it, you won't be able to see something readable. So the cracker can find the good one without knowing it.
Anyway, I will also check specialized forum, thanks ;)
-
You definitely should add a salt to make the passwords resistant against dictionary attacks. You need to store the salt along with the password of course:-)
I'd also increase the number of rounds in the hashing. That does not improve the quality of the output, but it makes it more costly to brute-force the password.
-
[quote author="Tobias Hunger" date="1312398468"]You definitely should add a salt to make the passwords resistant against dictionary attacks. You need to store the salt along with the password of course:-)
I'd also increase the number of rounds in the hashing. That does not improve the quality of the output, but it makes it more costly to brute-force the password.[/quote]
Hi !
I've got an idea. Ok for the salt, this is what I do: "SaltPassPassSalt" then hash.
And when creating an "identity" file, the user can see how much rounds can be done in 1 sec. And he will just have to choose how much he wants ^^'Isn't it a good idea? ;)
-
This is all cool and well you're doing, but please keep one thing in mind: You can't make a weak password good! You can't add entropy to a password doing static transformations as you do. I think it's good, really, to obfuscate a password and maybe render existing rainbow table attacks useless. And of course, whenever you store a password's hash somewhere permanently, you need to add salt to protect it -- ok, that's well understood.
But by all means, don't get the impression that suddenly, because someone enters "123" as password, and you salt and hash it, the quality or security improves. This might be obvious, but I'm just saying.... If somebody is interested, they can generate rainbow tables or whatever, but the algorithm itself doesn't gain real security (all because of the initial password's low entropy!).
-
Also, I would recommend that you work your hash rounds like your salt, generate a random number of hash rounds and store them for each user if possible, that way each user has a different number of rounds for his hashes.
-
Raul: What good is having a random number of rounds?
The rounds of hashing is done to make checking the password more expensive, which makes brute-forcing it harder.
Varying the number of rounds (which needs to be saved alongside the password/salt) will only enable an attacker to concentrate on those that are easiest to pry open.
-
Personally, I don't see the point in allowing passwords with little entropy at all. No matter how much you salt, hash, resalt and rehash these passwords, they are still insecure. I am not the first one to remark this, but I can not stress it enough. See LinusA' s answer.
I would simply stimulate the user to select a password that provides sufficient strength.
!http://imgs.xkcd.com/comics/password_strength.png(xkcd on password strength)!
(Image from xkcd.com)