Change Traffic Ops password hashing to scrypt #602
Conversation
|
I'll try to look at this tomorrow. thanks @rob05c |
|
sorry, i merged another PR that created a conflict for you... |
|
Fixed. |
|
i'm seeing this when i try to login [2017-06-07 10:59:36,931] [DEBUG] POST "/api/1.2/user/login". |
|
Ah, |
traffic_ops/app/lib/Utils/Helper.pm
Outdated
| return scrypt_hash($pass, \64, 16384, 8, 1, 64); | ||
| } | ||
|
|
||
| sub verify_pass { |
There was a problem hiding this comment.
how about a comment here describing what's going on? I assume it's for a gradual upgrade -- trying both crypt and sha1 for passwords that haven't been upgraded yet..
| @@ -28,7 +28,7 @@ use DBI; | |||
| use POSIX; | |||
| use File::Basename qw{dirname}; | |||
| use File::Path qw{make_path}; | |||
| use Digest::SHA1 qw(sha1_hex); | |||
| use Crypt::ScryptKDF qw(scrypt_hash); | |||
There was a problem hiding this comment.
doesn't appear to be in there.. please add to that module to traffic_ops/app/cpanfile
There was a problem hiding this comment.
There was a problem hiding this comment.
not sure how I missed that.. thanks..
zrhoffman
added
the
authentication
Note this is not a security vulnerability or mitigation in itself. In the event the database is compromised, it prevents an attacker from learning the users' passwords.
Which is the intention of hashing the passwords in the first place; but sha1 doesn't accomplish that. Nor does sha512, the problem isn't sha1's brokenness, it's that fast hashes aren't designed to solve this problem. The hash must be computationally slow ("slow" here means several milliseconds). Scrypt is a stretching hash, and solves the problem.