On Oct 29, 2:22 am, Christian Hammond <chip...@chipx86.com> wrote:
> I should point out for anyone else reading the notes that you were able to
> get away with not needing the old secret key because you're (I'm assuming)
> using something like LDAP or NIS or Active Directory. In these cases, we
> don't store an encrypted password in the database, so it should be fine.
> However, if you have *any* built-in auth accounts (like an initially created
> admin user), you'll probably want to use your old secret key. Or just use it
> anyway, it should be safe enough.

We're currently using built-in auth (we're hoping to move to LDAP/AD
soon as we already have AD setup for other stuff). Weird... I know!
Thought it was worth mentioning as it (potentially) saves a step.

I didn't purge cookies, I did have to login using the regular login
form so I think the auth really is working (rather than cookie
caching). I'm guessing the per-password salt is stored in the database
along with the HMAC rather than using the site setting shared key (but
this is just a wild guess).

I should point out that I'm not storing auth for SCM's (all the SCM's
we use do NOT use auth) which maybe where the shared key may be used.

If I get burned by this later with other security stuff I'll report
back :-)

Chris

--~--~---------~--~----~------------~-------~--~----~
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to