Password transformation for crypto app
-
Hi everybody !
I'm on a crypto app (http://qt.nokia.com/qt-in-use/ambassadors/project?id=a0F20000006MBBaEAO) using Qt.
When you start TagPG for the first time, you're asked to create an "identity", which is a file containing some cipher information, like cipher name (aes, ...), hash name (sha1, ...), Initialization Vector used, and private key.The thing is, the user can input any type of password he wants (hdjs§!@58#$^%£ or ppp), and I want to transform it, in order to make it longer, and more complicated when encrypting with AES.
Currently, I'm hashing the password with the hash name selected, and I'm using the hashed password (3 rounds) with the cipher, but for the generated RSA private key, 40 chars (Sha1) is too long for the passphrase (according to QCA, the crypto lib i'm using), so I have to take the first 20 characters.
SO... Here is my question. Does anyone have an idea on how to correctly transform the user password, in order to get a 20 characters password/passphrase, which will also be enough cryptographic secure, either begining from a complicated typed pass, or from a simple pass like "ppp".
Or, maybe my current method (using hashed password, and it's first 20 characters) is enough secure.Thank you for your help :)
-
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)
