Forum Moderators: phranque
Surely there's a better way than "username/password".
Since the website will be using SSL anyway, you might as well use SSL's certificate authentication to authenticate the user to the server as well as the server to the user.
Well first, is it really going to be a security improvement?(do you find login and password on a secure server, to be insufficient?) Second, is the possible added security worth the confusion etc. it may cause for your average computer user?
I think it would be an improvement.
I think that since most people use their computers at home and not on the road, that this wouldn't be too much of a problem. You could at least offer it as an option and let users toggle it on and off.
Note that I'm talking about sensitive sites like brokerages and banks, not just your average site requiring a logon.
An even better way would be to let people pick a username and password and the people would be smart enough not to tell anyone what it is :)
If they are using a straight username/password, they HAVE to tell someone else what it is. They have to tell their computer, and their computer has to tell the server. The server may store passwords encrypted, but it still handles the unencrypted password every time someone logs in. You have to trust your PC to be secure, and you have to trust the server to be secure.
One Time Passwords solve having to trust your computer, but the server still knows your master password to generate the OTPs to authenticate you.
If they are using a straight username/password, they HAVE to tell someone else what it is. They have to tell their computer, and their computer has to tell the server. The server may store passwords encrypted, but it still handles the unencrypted password every time someone logs in. You have to trust your PC to be secure, and you have to trust the server to be secure.
Um..., no.
Not under digest authentication. The password itself never goes over the wire. Just the authentication hash. Digest authentication is subject to theoretical man-in-the-middle attacks, but is quite secure especially when combined with SSL.
The problem with both basic and digest authentication is that the designers/site owners always seem to object to the plain old gray login dialog. They want it to be part of the page.
The workaround to this is to re-invent the wheel and use forms based logins that mimic digest authentication. The form data is processed using javascript to create the digest hash which is sent over the wire instead of the password.
The fact that the javascript is visible is immaterial because the MD5 hash employed is a one way hash. Observation of the resulting hash, and the algorithm employed does not enable a third party to recreate the hash without knowing the password except by brute force.
This has been working reliably on several sites over the last three years.
In order for this scheme to work it requires both session cookies and javascript to be enabled.
At one time it was possible to do this without the cookies, but Microsoft has removed the ability to use username:password in http requests in updated versions of IE.
+++
I think that since most people use their computers at home and not on the road, that this wouldn't be too much of a problem. You could at least offer it as an option and let users toggle it on and off.
When you say most you must mean in the neighborhood of maybe 51% because at my institution people are connecting from work and on the road all the time. Even if you were talking about 80%, would you want to turn away 20% of your business?
Even if we had IP authentication as an option we would still require a password because you do not want little Billy to have access to Mom and Dad's 401(k) funds.
When you say most you must mean in the neighborhood of maybe 51% because at my institution people are connecting from work and on the road all the time. Even if you were talking about 80%, would you want to turn away 20% of your business?Even if we had IP authentication as an option we would still require a password because you do not want little Billy to have access to Mom and Dad's 401(k) funds.
I'm just saying ti should be an option (in addition to username/password, not in lieu of it).
I'm just saying ti should be an option (in addition to username/password, not in lieu of it).
I am willing to consider it, provided the development costs are not prohibitive in relation to the number of affected users. I wonder if there would be any political concerns for example, "only rich people get the good security" kind of thing...
I wonder if there would be any political concerns for example, "only rich people get the good security" kind of thing
Isn't that the way it is with everything else? Life isn't - and shouldn't be - "fair" in a capitalist society.
If I have the cash in the bank, I can build a more secure house, put better locks on it, have a higher quality security system, hire guards, etc. If I don't have the cash for that, I don't have that security - period.
The same applies for "virtual" security. If I can afford a better programmer and develop a more secure solution, I shouldn't be obligated by any government to share it with anyone for any reason. If some people, even if it's the majority, can't afford YOUR product you would be pretty pissed if you were forced to drop your price. If your product was "security" it would be no different.
Using public/private key authentication, the attacker would have my public key, notable for the fact it is already public information.
Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified.
4.13 Storing passwordsDigest authentication requires that the authenticating agent (usually
the server) store some data derived from the user's name and password
in a "password file" associated with a given realm. Normally this
might contain pairs consisting of username and H(A1), where H(A1) is
the digested value of the username, realm, and password as described
above.The security implications of this are that if this password file is
compromised, then an attacker gains immediate access to documents on
the server using this realm. Unlike, say a standard UNIX password
file, this information need not be decrypted in order to access
documents in the server realm associated with this file. On the other
hand, decryption, or more likely a brute force attack, would be
necessary to obtain the user's password. This is the reason that the
realm is part of the digested data stored in the password file. It
means that if one Digest authentication password file is compromised,
it does not automatically compromise others with the same username
and password (though it does expose them to brute force attack).
H(A1) looks equivalent to the password (with respect to that realm) to me.
[edited by: DaveAtIFG at 4:13 pm (utc) on July 28, 2004]
[edit reason] Closed a "quote" tag [/edit]
post begins here, something wrong with the formatting of the post above this one
py9jmas, your assertion was:
Even with HTTP Digest authentication, the server knows my username and password.
No. Digest authentication *requires* that the password does not traverse the communications channel. The server is not *prohibited* from storing your password and deriving the communicated hash from it. However, servers implemented by the security conscious do *not* store the password, but instead store an *intermediate* value that can be used to *derive* the hash for comparison purposes. The intermediate value is created at the time the account is setup. For this reason, on such systems you are not able to recover the password if it is forgotten.
DrBrain has kindly provided the reference for you in RFC2617.
you further assert
H(A1) looks equivalent to the password (with respect to that realm) to me.
In a properly implemented system, H(A1) is not acceptable for the purpose of authentication. You are also presuming as a *precondition* that the authentication db has been compromised. As this should be the most protected asset on a system, access to any other file is *moot*. The server has already been had. I believe that the original discussion was predicated on over the wire authentication. It had nothing to do with a server compromise.
+++
Digest authentication *requires* that the password does not traverse the communications channel.
In a properly implemented system, H(A1) is not acceptable for the purpose of authentication.
You are also presuming as a *precondition* that the authentication db has been compromised.
I believe that the original discussion was predicated on over the wire authentication.
If you are assuming the server's password database is compromised, you must also assume that the server's private key has been compromised, since it must be stored on the server in order to encrypt a session.
In an encrypted system, both endpoints must be secure in order for the session to remain secure and there must be a chain of signatures between the two keys. Without this chain of signatures, the web of trust, you cannot authenticate.
The web of trust is a big problem with a PKI, since you must trust people to do the work of authentication, rather than a pre-agreed secret between two parties. Instead of just two people exchanging a secret, you now have N people you must trust in order to verify authentication. (Remember most SSL server certificates are not actually verified, reducing the security of the system.)
Since you're not trusting the server, then you must assume that the server's private key is compromised. The server must have the password to the private key in order to initiate an encrypted session. After that either the server's password or the unlocked private key is freely accessible to anyone with illicit access to the server.
(No, you may not wave about "magic" crypto hardware unless it comes with its own secure input devices as well. I am premptively countering with van Eck phreaking.)
If you bother to go read something about authentication, you'll realize that PKI is no better than a shared secret when endpoints are fixed. (Yes, fixed.) PKI has a huge benefit when the endpoints have not met each other, provided your web of trust is secure.
