| 2049
|
|
|
William Reade |
10 years ago
|
 |
|
| 2048
|
|
|
William Reade |
10 years ago
|
|
|
| 2047
|
|
|
William Reade |
10 years ago
|
|
|
| 2046
|
|
|
William Reade |
10 years ago
|
|
|
| 2045
|
|
|
William Reade |
10 years ago
|
|
|
| 2044
|
|
|
William Reade |
10 years ago
|
|
|
| 2043
|
|
|
William Reade |
10 years ago
|
|
|
| 2042
|
|
|
William Reade |
10 years ago
|
|
|
| 2041
|
|
|
Ian Booth |
10 years ago
|
|
|
| 2040
|
|
|
Andrew Wilkins |
10 years ago
|
|
|
| 2039
|
|
|
Ian Booth |
10 years ago
|
|
|
| 2038
|
|
|
Andrew Wilkins |
10 years ago
|
|
|
| 2037
|
|
[r=jameinel] state/unit/machine/user: change password hashes
This is a follow up to my previous PasswordHash changes, making it a
more complete step.
1) PasswordHash is split into 3 functions:
UserPasswordHash(password, salt) passwordhash
CompatPasswordHash(password) passwordhash {
return UserPasswordHash(password, oldDefaultSalt)
}
AgentPasswordHash(password) passwordHash, error
2) UserPasswordHash does the same 8192 rounds of pbkdf2 hashing to
ensure that it is hard to brute force a user's password. On top of
that, it requires a "salt" value.
state/User grows an added field PasswordSalt. Whenever we call
User.SetPassword we generate a salt and use that to compute the
password hash.
For compatibility, if User.PasswordSalt is the empty string, we use
the CompatPasswordHash which sets the salt to the old hard-coded salt.
I chose to use a different function to make it clear that we don't
really want to support empty salts.
3) User.PasswordValid(password) knows how to check both ways for
compatibility, and if it sees that the saved hash was not salted, it
calls SetPassword() immediately to set a salt and regenerate the
password hash.
4) For Machine and Unit agents, we change their hash function to just
be a simple SHA-512 of the password. We don't bother with a salt or
with iterated pbkdf2. This is because we know that agents have very
high entropy passwords (utils.RandomPassword uses 18 bytes of entropy
or 2^144). This is not really feasible to brute force, so there isn't
really a point to salt or iterate.
As part of this change, AgentPasswordHash(string) string, error can
return an error if it appears the password might not have enough
entropy (for now we just check the length of the password). That way
someone can't accidentally get rooted because they set the machine-0
agent password to "foo".
This probably had the widest effect as we had a lot of tests that set
a simple password just so we could login as that agent, but we just
change it so we use utils.RandomPassword in all of those places.
As mentioned before, this is a big performance win when scaling up to
thousands of agents. Timing shows UserPasswordHash takes about 80ms,
while AgentPasswordHash takes about 8us. PasswordHash was dominating
the time it took for the system to recover after restarting the API
machine.
5) Similar to User.PasswordValid, Machine.PasswordValid and
Unit.PasswordValid will do a fast check using AgentPasswordValid, and
if that fails, they will fall back to the slow CompatPasswordValid. If
they find the passwordhash is a compat value, they reset the value to
the fast-path value.
https://codereview.appspot.com/21000044/
|
John Arbash Meinel |
10 years ago
|
|
|
| 2036
|
|
|
Dimiter Naydenov |
10 years ago
|
|
|
| 2035
|
|
|
John Arbash Meinel |
10 years ago
|
|
|
| 2034
|
|
|
Nate Finch |
10 years ago
|
|
|
| 2033
|
|
|
Frank Mueller |
10 years ago
|
|
|
| 2032
|
|
[r=jameinel] rpc/apiserver: logging improvements
This is a bunch of tweaks to the RPC logging statements to make them
nicer to use.
1) Add wall-clock time to responses. This lets you see quickly how
long a given RPC took to process.
2) Add a unique identifier per-connection. The code was sort of
written around remoteAddr (it collected it, at least), but it turns
out that isn't actually enough. Roger mentioned using the address of
an object, but those can be reused. Using a unique counter allows us
to both guarantee it is unique for the lifetime of the process, and
makes the numbers significantly smaller. I also went with Hex form
to save a couple bytes, but I'm not wedded to it. I could be
convinced that %d would be better than %x. I did go with [%x] to
ensure that you can search for a stream without hitting
prefix/suffix/etc matches.
3) Once the remote side has logged in, the log messages include the
Tag of that entity. I find that to be quite useful (especially to
clarify unit agents from machine agents, etc). The Facade they are
using is already in the requests (as Type).
This is based on my earlier patch that fixes the API endpoint bugs. I
could pull it out if that patch gets rejected, as it isn't an actual
dependency, just code committed after the other one. I don't expect it
will be an actual problem, though.
https://codereview.appspot.com/18990045/
|
John Arbash Meinel |
10 years ago
|
|
|
| 2031
|
|
|
John Arbash Meinel |
10 years ago
|
|
|
| 2030
|
|
|
Andrew Wilkins |
10 years ago
|
|
|
collapse all