I am trying to understand gmail's authentication mechanism. I know it uses https for transporting the user credentials during login and then the rest of the communication happens over http. How is this achieved? Is some kind of key exchanged during the initial session over https and used in subsequent requests? if yes, Isn't some kind of key agreement protocol (e.g. Diffie-Hellman) better for exchanging the shared key instead of https?
https uses asymmetric encryption to obtain a symmetric key. After cookies are set using https they are the source of authentication over http. Unless the user has set https to be always used
Related
I understand the XSS vulnerability of using web storage and the CSRF vulnerability of using cookies. So I store the access token in memory and for persistence I have a refresh token in a cookie which I use to silently refresh my access token when we lose it. I feel somewhat better about XSS and CSRF threats... BUT how do we secure the token from a packet sniffer? A packet sniffer would find the token in the request. I see a lot of discussion on XSS and CSRF but how do we keep safe from packet sniffers, and are there even more threats we do not commonly think about?
You use HTTPS to defend against packet sniffers.
Fiddler as a proxy will not be able to decrypt HTTPS traffic in the cloud unless the fiddlers built in root certificate is added to the browser or client making the request.
Fiddler is able to decrypt HTTPS because you have added Fiddlers root certificate to your trusted store in YOUR computer. without this a proper HTTPS connections can't be made.
So , don't worry about Fidler in the cloud.
https provides an end to end encryption. Its implenented on the application level by browsers so no other users on the same network doesnt break https security.
The below is a short explanation of how ssl and https (http over ssl) works
Ssl:
The key idea is that mathematically you can generate a public key A and a private key B in a way that if you encrypt something with A you can only decrypt it with B.
So let's say the server google has a pair of public key A and private key B.
A client wants to send some data to google. The idea is if the client has key B he can encrypt the data he wants to send and he doesnt care anymore of network threats such as a man in the middle fishing the packet or data because only the owner of key B (google) can decrypt the data. So the man in the middle will only have encrypted data which has no use.
Note that from above it is clear that servers (google here) should keep their private key unshared, but should distribute their public key so that clients can use to communicate safely (with encryption) with the server.
How to distribute the public key ?
Using the public key infrastructure (PKI) which is a set of roles, entities, definitions, etc. used to manage and distribute public keys.
Again in short, a server request a certificate from a certificate authority (CA). That certificate contains information on the server (name, ip, etc.) And the public key and private key generated for that server (note here there are several procedures that a server might request to generate the keys, one of which is the server generates the private key and the CA only responsible for generating the public key).
Finally, there is a list of trusted CAs built into the browsers, so that these browsers such as chrome can go to and get google's public key A, and use it to encrypt the data it wants to send to google.
The above is how ssl communication protocol works (ssl certificates). Ssl is simply a protocol that provides secure communication. It provides no routing and networking capabilities.
Https:
Https is basically HTTP connection which is delivering the data secured using SSL.
That means SSL encrypted data will be routed using protocols like HTTP for communication.
Does there exist any authentication protocol which is safe on unsecured channel? Session id's are easily hijacked by MitM, so which mechanism are used to make the session secure on unsecured HTTP channel?
For HTTP Following Authentication Schemes are useful.
Basic rfc:7617
Bearer rfc:6750
Digest rfc:7616
HOBA rfc:7486 refer section 3
Mutual rfc:8120
AWS4-HMAC-SHA256 aws:docs
Also a good detail explanation could be found here
Hope it is useful.
Authenticating against a server over HTTP is problematic as without a server certificate, you can't be sure you are actually communicating with the intended server. Also, any credentials being sent to the server are susceptible to eaves-dropping.
Having said that, there are authentication protocols that can be used securely over HTTP once the server and client have exchanged a secret over a secure channel. Protocols like Hawk or AWS signatures do not require HTTPS for every subsequent request.
I am curious how to properly send username and password from a website login form to a server.
If I just send the username and password without hashing them to an https server how exposed is the password I send in a POST request to somebody sniffing the package and finding out the password? The server is https enabled.
What would be the proper methodology to do this?
If the server is HTTPS enabled then any data going over the wire will be encrypted. It would be extraordinarily difficult for a network-only attacker to sniff even a plaintext password over HTTPS without one of the parties noticing.
HTTPS uses SSL/TLS on the transport layer, which is designed to provide both encryption and authentication. The SSL/TLS protocol, as part of its handshake, negotiates a symmetric encryption key that is different for each session and is used with a strong algorithm to protect data on the wire.
To mitigate 'man-in-the-middle' attacks, the asymmetric keys used by the client and server to establish a shared encryption key are also cryptographically signed by a certificate authority, both to provide assurance of trust and to prevent modification of the certificate. As long as the certificate authority can be trusted, it is easy to check the signature and and server name on the certificate itself. All modern browsers do this automatically and throw a warning to the user if there is any problem with the certificate.
As long as you and your users are aware of the issues surrounding the proper use of SSL (e.g. keep your private key safe, and make sure your users pay attention to browser warning), it's fine to send plaintext passwords over an SSL connection.
If the demands of your application are such that you cannot do even that, you might consider X.509 authentication (which uses certificates on the client side as well as the server side) or Kerberos authentication (which sends no passwords over the wire). For a basic web application, though, both of these solutions are overkill.
I'm reading the API for a web service, and all methods involve sending an HTTP request to
https://example.com/api/APIVER/METHOD?apikey=APIKEY&user=USERNAME&password=PASSWORD
To be clear, both the API key and user password are sent in plain text via the URL. But is this OK because "all HTTPS traffic is encrypted" or not because they're still in plain text or because the URL is somehow different?
If this isn't secure, what is the minimum change the API maintainer needs to do?
Yes, HTTPS makes this more secure.
HTTPS makes this more secure.
You should also send sensitive parameters as POST parameters instead (HTTP BODY) of GET query string ones. Typically the query string will be logged by Web server logs (server side) in plaintext, so it will be accessible to system administrators that perhaps shouldn't be able to see it.
HTTPS will encode the URL in each request, so if you are worried about network sniffing then you're OK. HTTPS also adds a nonce value, so you aren't exposed to reply attacks.
It would be possible, depending on infrastructure to insert a fake SSL certificate that's trusted by the user device and route requests through a proxy using that certificate. However this would require admin/root access to the client machines to make such a certificate trusted (barring breach of a normally trusted CA), and once something needs admin access all bets are off anyway.
It's still not a wonderful idea though, I'd be concerned about developers forgetting to configure it for HTTPS. You have an API key, so why not take the password and hash it using the APIKEY as the salt. Now for the API calls the salt is a password equivalent but it would mean that the username and password couldn't be used for logging into elsewhere with those credentials, for example the web site that the API is running off (assuming you let users log in there of course.)
Even better would be to use a shared secret that doesn't go over the wire at all, and use that as the salt.
any request is made via HTTPS and the token is transmitted the following ways:
a) GET https://foo.dom/foobar?auth_token=abcxyz
b) GET https://foo.dom/foobar with HTTP-header like X-FOOBAR-TOKEN: abcxyz
As I understand SSL, in case of an HTTP request the client first negotiates the SSL connection and does only transmit additional parameters and/or HTTP headers in case the secure connection was established successfully.
Am I right so far?
Thx fur any suggestion.
Felix
SSL buys you encryption of the transport so no one can snag the auth token while it is being sent/to from the site. There are some man-in-the-middle attacks that can be performed against SSL but generally SSL should protect the token content.
What makes or breaks the security is whether or not the Token it-self is cryptographically secure. If that can be said to be true then your are golden. Check out this site http://web.mit.edu/kerberos/dialogue.html.
There are plenty of other sites that use secrue tokens for auth, see: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html.