|
|
|
|
| Re: [CDO] server-side password hashing [message #1833319 is a reply to message #1833301] |
Fri, 09 October 2020 06:13   |
|
In general it's possible, and probably good, to store the result of a one-way function (hash, digest). And in theory the authenticator (org.eclipse.emf.cdo.server.internal.security.SecurityManager.Authenticator) would be able to apply the same one-way function to the clear-text password that is received from the client (the wire protocol uses Diffie-Hellman key exchange, i.e., no clear-text password over the wire), and then compare the result to the stored hash. But the SecurityManager is built on top of the Security model, and the Security model, which keeps the user credentials in memory, does not know about the SecurityManager. If you open the Call Hierarchy on the following two methods you'll see that there are a few paths that don't necessarily go through the higher SecurityManager:
org.eclipse.emf.cdo.security.UserPassword.getEncrypted()
org.eclipse.emf.cdo.security.UserPassword.setEncrypted(String)
I see no easy way to inject a one-way function into the Security model itself. Note that there may be many copies of this model, each managed by its own CDOView/CDOTransaction. If you find a way I'll be happy to review a respective patch.
The storage layer-only approach that I proposed is fully symmetric and requires an attacker to gain control over the running VM. In that case, in theory, she could decrypt the user passwords. But then that's probably not the only problem. If your users' passwords must be safe even in this case, I'd need funding to implement and test a more complex solution.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.02772 seconds
Search
Help
Register
Login
Home
