Timeline for Set a hash, login with a password?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 17, 2017 at 16:07 | comment | added | Mike Ounsworth | Makes sense, thanks. I agree that the attack surface is very very small, but policy says "memory containing passwords must never be returned to the OS un-zeroized". So I dance. Sigh. | |
| Feb 17, 2017 at 8:42 | comment | added | Tim X | Sorry, I didn't mean to make this hard. I just found your statement "all of this is local on the physical keyboard of the server". this being the case, the only MitM attack possible means your server is compromised, in which case the game is over already. My original interpretation was that steps 1 .. 3 were initiated remotely (so MitM is a concern) and I wasn't sure how you did the initial authn to allow user to set initial hash. Based on everything being local, the scheme is just adding complexity. | |
| Feb 17, 2017 at 3:37 | comment | added | Mike Ounsworth | Uhh wat? I really regret that I even attempted to explain my use case at all. Yes everything is local to the server box. The application deployment and initialization is orchestrated by a scripting language that I don't have very much control over. User accounts are created (and passwords set) as part of this process, via the scripting language as users don't want to stand there for the several hour deployment, waiting for a prompt. Once the application is deployed and running, subsequent logins are handled directly to the application via keyboard, passwords are handled properly, etc. | |
| Feb 16, 2017 at 21:12 | comment | added | Tim X | So, if all interaction is via the keyboard directly connected, then your 'client' for initial hashing is really your server? This would mean the hashing is still done on the server, just with different language to the bulk registration code i.e. not immutable language so memory concerns don't exist as you are able to zero password variables afterwards? | |
| Feb 16, 2017 at 20:37 | comment | added | Mike Ounsworth | The answer is that my use-case is actually pretty narrow: there is no "wire", all of this is local on the physical keyboard of the server. The authentication mechanism is to check their ID badge before allowing them into the server room. So, I have to agree with your second point: worrying about an attacker having access to a memory dump is probably more of a philosophical debate than a practical one. Point taken. | |
| Feb 16, 2017 at 20:22 | history | answered | Tim X | CC BY-SA 3.0 |