Good catch Darren - the plain text authenticator was only preserved to support older clients that still hashed their passwords to md5. Indeed, storing the hash type would be required so only the appropriate authenticator would be invoked. However, we need to ensure that upgrades are correctly handled, since in older installations, we need to know which users used what encoding type. After that, the plain text authenticator should be disabled/removed.
For the immediate future, we should disable the plain text authenticator by default and rel-note it to say that it should be used only if older clients still exist and need it - and that these clients should first change their users' passwords via updateUserCmd so the new passwords get SHA encoded, and then the clients must be changed asap to use plain text passwords. Regards, Vijay On 9/12/13 9:56 AM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >So if you set your password as blah and it gets hashed to xyz and stored >in the users table. Because of the plain text authenticator, you can >use that hashed value as your password now. So specifically the below >will work. > >http://localhost:8080/client/api?command=login&username=user&password=blah > >http://localhost:8080/client/api?command=login&username=user&password=xyz > >This seems bad. Go and try it yourself (just be careful about URL >encoding, + should be %2b). So because of the existence of the plain >text authenticator, passwords are still plain text but they just happen >to be long random strings. Typically in an auth system you store the >hashing type with the hashed value. So then the plain text >authenticator would not even attempt to compare values because it would >see the value was hashed by a different authenticator. > >Darren
