0

Im using AES and a salt String to encrypt my 'passwords', using a java program I made. (It uses AES symmetric encryption)

The user sets the message to be encrypted, the salt, the iterations, and 16 bytes for the key.

If i set it to use a high number of encryption and decryption iterations, say 255, will that really make my password any MORE secure than 1 iteration?

Primm
  • 1,347
  • 4
  • 19
  • 32
  • 2
    You should be using some sort of hashing algorithm to save passwords. – Dan W Jul 10 '12 at 17:10
  • What OWASP says : "passwords should be hashed, NOT encrypted" (source : https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#hashing-vs-encryption) – Guillaume Husta Aug 12 '21 at 09:38

3 Answers3

8

The short answer is no. Adding iterations of encryption does not help. This is different to adding rounds in the underlying algorithm, where more rounds does, in fact, help.

The longer answer is that you are using the wrong technique for storing passwords. You shouldn't be using symmetric encryption, you should be using a one-way hashing function such as bcrypt.

The weakness in your solution (symmetric encryption) is that the encryption key must be available to your software in order to encrypt or decrypt a password. That means that when an attacker breaks in to your system they will be able to obtain both your password database and the key, so it will be trivial for them to then decrypt all the passwords. You should assume that an attacker will be able to obtain your source code as well as all your data.

If you use a hash function then you don't need to worry about this scenario. Even if an attacker obtains your source code and the password database they still cannot reverse the one-way hash (assuming you use a good hash - again, consider bcrypt), so theft of your data does not compromise your users' passwords.

When you are thinking about security it is almost always best to use an existing solution (did I mention bcrypt?) rather than rolling your own. Security is hard to get right, and even the experts screw it up. Don't write your own password storage system. Use one that was designed by the experts and, more importantly, has been analysed and attacked by a legion of other experts. Bcrypt, for example.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
  • Adding traditional iterations does help. I cite Triple DES (though this does also increase key size) – Wug Jul 10 '12 at 17:11
  • Well, DES was a particularly broken algorithm in the first place. AES does not have the same weaknesses as DES, and I have not seen any claims that encrypt-decrypt-encrypt would solve any weaknesses that AES may have. – Cameron Skinner Jul 10 '12 at 17:12
  • Yeah, it would SEEM that the iterations would be just another variable that has to be exactly right for a decryption to be succesful. – Primm Jul 10 '12 at 17:12
  • @user1332495: It would seem that way, but it's not. Remember that the attacker has just stolen your source code and all your data. They know how many iterations were used. – Cameron Skinner Jul 10 '12 at 17:13
  • what if they simply have your encrypted password? then they have to guess how many iterations were used. – Primm Jul 10 '12 at 17:14
  • @user1332495: You can't assume that. It would be very foolish to think that the attacker only took some of your data, not all of it. – Cameron Skinner Jul 10 '12 at 17:15
  • AES has at this point no weaknesses. Full single DES is considered weak because its small key size potentially within the realm of a brute force attack. There isn't anything you can do to increase poor security brought on by small keys because one can simply brute force all of them, but reapplying the encryption from scratch doesn't really do more than simply adding more rounds anyway. – Wug Jul 10 '12 at 17:15
  • im assuming, for this example, they have your encrypted data. any source for an encrypter would never be accessed. Also, you (the user) (in my program) set the iterations, salt, key manually, and they must be inputted to decrypt. sorry for the confusion. – Primm Jul 10 '12 at 17:16
  • @user1332495: Well, don't assume that. Not if you want to have strong security. – Cameron Skinner Jul 10 '12 at 17:18
  • I would run encryption locally, on my pc, which is not hooked up to the internet. then, i would copy and paste the encrypted code onto a flash drive, bring it to another pc, and email it. the receiver would already know the iterations, 16 bytes for the key, as well as the salt. this would (if i am learning correctly) be almost uncrackable. – Primm Jul 10 '12 at 17:19
  • one of the premises of cryptography is that you HAVE to assume that the attackers have ALL of your data, including the program you used to encrypt or hash, but that the data is still secure anyway, because analysis of the algorithm won't make it any weaker. – Wug Jul 10 '12 at 17:20
  • yes. exactly! the application itself is useless w/o the iteration count, salt, encrypted message, and key – Primm Jul 10 '12 at 17:20
  • the only thing you are allowed to say is secret is the key. It doesn't take that much effort to guess a few dozens of possible iteration counts. – Wug Jul 10 '12 at 17:23
  • 1
    Don't fall into the trap of thinking that adding more parameters makes your security stronger. **It does not**. The whole point of symmetric encryption algorithms like AES is that the key is the secret, nothing else, and that key is strong enough to protect your data. If you want to make it harder to brute force then make the key longer - use AES256 rather than AES128. This will make it 2^128 times as hard to break. Adding a "secret" iteration count will make it maybe 100 or 200 times as hard to break. Don't bother: keep it simple and stick to what the experts use. – Cameron Skinner Jul 10 '12 at 17:24
  • Adding extra parameters that are not true secrets will just make it more likely that you have a bug, and bugs make it easier to leak secrets. – Cameron Skinner Jul 10 '12 at 17:25
7

The short answer is yes.

Think of it like a Rubik's cube (It's not really the best example but bear with me). The plaintext is the cube in its solved state, the ciphertext its scrambled state. Each round of encryption is rotating one face of the cube once. It's computationally much more difficult to solve the cube in the shortest possible number of moves if its more heavily scrambled. Breaking one round of AES would be the cryptographical equivalent of asking someone to solve a Rubik's cube with one face rotated.

One such attack that can solve reduced rounds of encryptions efficiently is a SAT solver attack.

You should be using one way cryptographic operations for storing passwords anyway. I believe the preferred method is bcrypting, because it's cryptographically secure (one way) and computationally intensive and thus very difficult to brute force.

Wug
  • 12,956
  • 4
  • 34
  • 54
  • 2
    Remember that *rounds* in the underlying algorithm are not the same as adding *iterations* of encrypting and decrypting. AES(AES('foo')) is no better encrypted than AES('foo'). – Cameron Skinner Jul 10 '12 at 17:10
  • its another variable that has to be perfect for a successful decryption, multiplying the time it could take to decrypt! – Primm Jul 10 '12 at 17:13
  • 2
    Well, AES is fixed at 10, 12 or 14 rounds depending on key size, so it's not something you can change. I'm pretty sure he meant iterations, though I could be wrong :) – Cameron Skinner Jul 10 '12 at 17:19
  • I'm pretty sure there are practical breaks against as many as 7 or 8 rounds of AES using SAT solvers. – Wug Jul 10 '12 at 17:21
  • Also, it occurs to me 5 years later, @CameronSkinner, it is actually more secure to encrypt multiple times, provided you use different keys (see triple-des as a real world example). The key bit is that, for an ideal encryption algorithm, there is no difference, but real world algorithms are never perfect, they can only approach perfection, and applying more iterations can, under some circumstances, help you approach closer. Still, if you're doing this in practice, you're probably doing something terribly wrong. – Wug Jun 19 '17 at 00:49
1

Yes, more rounds will make the encryption stronger against certain attacks. But you should only store salted, hashed passwords. Don't encrypt them. That way, if someone steals your database they can't decrypt the passwords.

John Watts
  • 8,717
  • 1
  • 31
  • 35