network profile
| bio | website | |
|---|---|---|
| location | Belgium | |
| age | 45 | |
| visits | member for | 8 months |
| seen | Apr 9 at 19:28 | |
| stats | profile views | 4 |
|
Sep 25 |
awarded | Supporter |
|
Sep 25 |
awarded | Scholar |
|
Sep 25 |
comment |
bcrypt: random salt vs computed salt Thanks, I'll probably add some pepper to the mix :) |
|
Sep 25 |
accepted | bcrypt: random salt vs computed salt |
|
Sep 25 |
comment |
bcrypt: random salt vs computed salt Thanks, that answer actually made sense :). The fact that the algorithm used to calculate the salts can not be changed once it's in use is indeed a problem. If the hacker, one way or the another, obtained the algorithm used to compute the salts, then even changing the passwords won't change the salt for a user. I'll mark this as the best answer. |
|
Sep 25 |
awarded | Student |
|
Sep 25 |
comment |
bcrypt: random salt vs computed salt @Polynomial: nice article you linked and wrote, but most of it I already knew. But I don't see what could be the issue with computed salts. Of course, in an ideal world we would detect when a hacker gains access to our db, but what if a hacker gains undetected access, dumps our user table and quietly leaves. He now has access to the plaintext salts and can brute force the passwords. In this case, isn't it safer not to store the salts ? And I don't understand your remark about collisions. If the salt is hidden, the hacker won't even know if there was a collision between 2 computed salts. |
|
Sep 25 |
asked | bcrypt: random salt vs computed salt |
|
Sep 25 |
awarded | Analytical |
|
Sep 25 |
awarded | Autobiographer |
