I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Do I need to use mod_auth_digest?
Depends on what you mean by "as cleartext". In the HTTP basic authentication exchange, passwords are sent as cleartext (encoded as base64). But the whole exchange is tunneled through the encrypted SSL connection, so you can't see them by observing the traffic. (Unless you've successfully compromised the SSL connection itself and can see all the traffic.) When doing basic auth through HTTPS/SSL, the server at the other end can still see your passwords as cleartext, but it's sufficient to protect against man-in-the-middle eavesdropping.
I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Yes. Its transmitted in the clear within the SSL/TLS tunnel.
Do I need to use mod_auth_digest?
That's usually a problem, too.
The problem is that anyone that answers with a certificate is accepted. More correctly, the tunnel lacks "channel binding", where app authentication is part of the channel setup. So if someone intercepts the communication (i.e., proxy) or impersonates the up the server (phishing), then you send him/her password or MD5(password).
Its better to use a SSL/TLS protocol like TLS-SRP or TLS-PSK. Each use shared secrets like passwords, and each properly bind the channel. And both don't do dumb things like put the password on the wire in the plain text.
You can read more about these problems and solutions in Peter Gutmann's Enginerring Security.
Related
I've been reading and trying to comprehend the differences in browser side security. From what I gather, SSL is used to keep people from sniffing the traffic you send to the server. This allows you to send a password to a server in clear text...right? As long as you are in an SSL encrypted session you don't have to worry about hashing the password first or anything weird, just send it straight to the server along with the username. After the user authenticates you send them back a JWT and then all future requests to the server should include this JWT assuming they are trying to access a secured area. This allows the server to not even have to check the password, all the server does is verify the signature and that's all the server cares about. As long as the signature is verified you give the client whatever info they are requesting. Have I missed something?
You are correct. "This allows the server not to even have to check the password." Why would you have to check a password on each request?
A JWT is a means of verifying authentication. It is generated upon a successful authentication request and hence forth passed with each request to let the server know this user is authenticated.
It can be used to store arbitrary values such as user_id or api_key but they are not very secure so don't store any valuable information here.
Be wary though, if a plain JWT is intercepted by a third party, it can assume this user's session and possible data.
SSL is a lower level form of security, encrypting every request from and to the server to prevent interception and retains integrity.
SSL is achieved by (purchasing) an SSL certificate and installing it on your server. Basically an SSL certificate is a small data file that binds a cryptographic key to an 'organisation'. Once installed succesfully, HTTPS requests (on port 443 by default) are possible.
This is probably a dumb question but can I do away safely with just basic HTTP auth or do I still benefit from digest auth even if the server is already on SSL?
The only advantage you would gain by using HTTP Digest authentication over SSL/TLS is to prevent the disclosure of the user password to the server itself, if your sever is capable of being configured with passwords in "HA1 format" directly (i.e. if it doesn't need to know the password itself, but where the user password can be configured with MD5(username:realm:password), without requiring the password in clear, see Apache Httpd for example).
In practice, this isn't really a big advantage. There are better alternatives if protecting the password itself from the server is required (in particular because MD5 isn't considered good enough anyway nowadays).
The other features of HTTP Digest authentication (over form/HTTP Basic) are already provided by the SSL/TLS layer.
Across ssl basic auth is secure enough for most needs.
My client-side code calls the REST WCF service for changing passwords. I defined changePassword with "UriTemplate" set to "?user={userName}&oldPwd={oldHashPwd}&newPwd={newEncryptPwd}"
My question is: how to encrypt the new password on the client side so that we can successfully decrypt it on the server side ? Please be specific. Thanks.
Use HTTPS. If the whole communication is encrypted, you won't even need to encrypt/decrypt the password individually.
Beyond HTTPS, you could use a secure, salted password hash on the client side. That would mean even interception of the URL would be safe - having the hash would allow efficient "proof of ownership", but not discovery of the password.
Yinfang. You don't need to be worry to encrypt your password from client side that would only be decrypted on the server side. Now a days, there are so many channels through which you can protect you personal data like your passwords. One way is to check that whether yo use "HTTPS" for your browsing because it will provide you secure channel to send you information from one place to another.
On the other hand you can get VPN connection. Through which all of your information gets encrypted and provided secure channel to pass your personal sensitive data from client side to server. There are so many providers of VPN connection are available in the market like PureVPN, Hidemyass,switchvpn etc etc. If you want all of your information encrypted ans secure you can use these useful information.
Hope this could help. I use to encrypt data using Rijndael
Sample code here:
Cryptography
You can create logic on backend side and be used by the client side for encrypting and decrypting data.
You have 2 options to go with either "https" or "VPN/Proxy". Going through 'https' won't hazel much while encrypting anything on the web. I will give you smooth path to surf the web and do whatever you want. But the point is that if you are looking to get something more than just encryption then you should try VPN/Proxy. If you can google around then you will find that proxy is not that much safer. However, going through VPN is completely opposite to proxy. VPN is one of the best and most reliable feature that a user can have for their web. VPN absolutely anonymize one's identity and allow the local ISP to surf (encrypt/decrypt) user data with out any threats from hackers.
If I'm connecting to a mail server over SSL or TLS but using PLAIN authentication, is that secure?
Since the SSL/TLS connection is already encrypted, sending the password as PLAIN text doesn't hurt anything. You could encrypt the password as well, but then you're just double encrypting it. In most cases, I would consider that superfluous.
One case I can think of where you would use something other than PLAIN over SSL/TLS is if you choose to authenticate with certificates instead of passwords. Otherwise, I'd leave it at PLAIN.
Ryan is absolutely right if you are sure if you will never use your application without SSL. SSL is at the presentation layer and whenever a socket connection is established, SSL handshake is the first thing that happens which includes host verification, exchange of session keys and creating a secure transport layer. Communication at the application layer happens once this secure channel is established and the data that is exchanged is encrypted using the session keys and hence the communication is anyways secure.
However, if your application has an option to work with/without SSL then you should be encrypting your password separately. While working over SSL, this would be redundant but otherwise it is necessary.
I apologize before hand if this is an obvious question: can Apache 2.0 + SSL + basic authentication be trusted in order to secure a website? The way I see it, SSL creates a secure connection between the client and the server and thus any HTTP requests containing the clear-text password should not be a security issue.
thanks,
S.
You are correct, basic auth is secure as long as you can guarantee the connection is end-to-end encrypted. This means that you must configure the server to force SSL usage by redirecting HTTP requests to HTTPS, or not accept unencrypted connections at all for that URL.
"The only fully secure computer is one that is unplugged and turned off"
That said, Jim's answer is Good Enough if you accept SSL level of security :)