Timeline for Reasonable security measures for unvalidated "login"
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 31, 2019 at 20:40 | vote | accept | Bob.at.Indigo.Health | ||
| Aug 31, 2019 at 20:37 | comment | added | Bob.at.Indigo.Health | Thanks! Now that I've read the answer(s), I realize that the bad smell I had was mostly about exposing the primary keys. I'm actually doing the "invalidate upon use" thing already, and I was planning on cryptographically obscuring the primary key, but I like the idea of nuking both the key and the token and using a token (a Type 4 GUID) that exists in a table that gets a new entry each time I send a new email. | |
| Aug 31, 2019 at 16:27 | comment | added | Conor Mancone | I agree with all of the above. The only small change I would suggest is that I really doubt there is any reason to have the primary key in there in any form, either as the I'd or as an HMAC. Therefore, just kill it. Make sure the token is unique and then you can look up the primary key from the token. You'll want the token column indexed for quick lookups, so adding a unique constraint on the token column will kill two birds with one stone | |
| Aug 31, 2019 at 1:51 | history | answered | CBHacking | CC BY-SA 4.0 |