Timeline for Use of CBC-AES-256 to encrypt usernames
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 17, 2013 at 22:57 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
deleted 76 characters in body
|
| Feb 16, 2013 at 4:33 | vote | accept | amaterasu | ||
| Feb 14, 2013 at 12:01 | comment | added | fgrieu♦ | @Gilles: Yes, proper encryption of part of a database protects against adversaries which only manage to get access to the encrypted version of the database; thus is not useless. Problem is, if general security measures can't prevent an access that no user should have, why would they better prevent against regular access to the deciphered data (which some users must have), or access to the key, or to the device/process that can decipher using the key? | |
| Feb 14, 2013 at 10:20 | comment | added | Gilles 'SO- stop being evil' | Encrypting part of the database does protect against some attacks: SQL injection (if the key isn't in the database and the injection cannot be escalated), leak of plaintext backups. | |
| Feb 14, 2013 at 7:50 | comment | added | fgrieu♦ | @amaterasu: AES-256 uses 16-byte, not 32-byte blocks (only the key is 32-byte); and, depending on encoding, that might be good for 16, 8, more or even less characters. If the IV is global, indeed CBC and ECB are equally insecure when all names fit in a block, and CBC is marginally less insecure above that threshold. | |
| Feb 14, 2013 at 7:12 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
considerations on securing an online database
|
| Feb 14, 2013 at 7:03 | comment | added | amaterasu | Yes, only one IV is being used. If the encryption works with 32byte blocks and usernames are always shorter than that, what is the point in using CBC over ECB if there is only one IV being used? | |
| Feb 14, 2013 at 6:55 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
Add the hypothesis that the adversar can add chosen usernames, and a tad of justification
|
| Feb 14, 2013 at 6:46 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
Expand with consideration on encoding of the usernames.
|
| Feb 14, 2013 at 6:34 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
Update taking comment into account.
|
| Feb 14, 2013 at 6:30 | comment | added | Thomas | @amaterasu Doesn't that mean he can brute-force every username if you are reusing key+IV? | |
| Feb 14, 2013 at 6:30 | comment | added | Seth | @amaterasu When you say the "key an IV are hardcoded and used for every username" do you mean that only one IV is being used? Each username must have its own IV, and in CBC mode, each IV needs to be a random 16-byte value. It's fine if the attacker sees the IVs, so you can go ahead and store them in the database. | |
| Feb 14, 2013 at 6:26 | comment | added | amaterasu | They key and IV are hardcoded and used for every username. An attacker is able to register new usernames and see the ciphertext of them if he has access to the SQL db. | |
| Feb 14, 2013 at 6:25 | history | edited | fgrieu♦ | CC BY-SA 3.0 |
Expand
|
| Feb 14, 2013 at 6:20 | history | answered | fgrieu♦ | CC BY-SA 3.0 |