Login without HTTPS, how to secure?

For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure? E.g.:

• Tokenize logins, to make repeat attacks difficult?
• Somehow encrypt the sent password from a HTML password field?

In particular I'm using CakePHP and an AJAX POST call to trigger authentication (includes provided username and password).

Update on the problem:

• HTTPS is not available. Period. If you don't like the the situation, consider it a theoretical question.
• There are no explicit requirements, you have whatever HTTP, PHP and a browser (cookies, JavaScript etc.) offers in real life (no magic RSA binaries, PGP plugins).
• Question is, what is the best, you can make out of this situation, that is better than sending the passwords plaintext. Knowing the drawbacks of each such solutions is a plus.
• Any improvement better than plain passwords is welcome. We do not aim for a 100% l33tG0Dhx0r-proff solution. Difficult to crack is better than complicated to hack which is better than a trivial sniffing revealing the password.

HTTPS is absolutely vital in maintaining a secure connection between a website and a browser. Public wifi networks put users at risk, and when used correctly, HTTPS is the only tool that can protect user accounts from this vulnerability.

If your host doesn't support HTTPS then a service like Cloudflare Universal SSL can be used to ensure all browsers connect to your site using HTTPS, even if your server doesn't support SSL/TLS. The connection between Cloudflare and your website will still be unprotected, but this Cloudflare service is intended to protect users against threats found on public wifi networks. From the perspective of a penetration tester, not providing HTTPS is highly suspect, if you aren't providing a basic security requirement as delivering traffic, then what other security requirements are you missing? HTTPS certificates can be obtained for free using Let's Encrypt or Start SSL, there is no legitimate reason not to support HTTPS.

HTTPS is vital because it does lot more than just "encrypt passwords". Another important role is that it should prevent the user from giving logging into a malicious server that is impersonating a real server. Using a system to protect the password alone is still a violation of OWASP A9 - Insufficient Transport Layer Protection because you would still be transmitting session credentials in plain text which is all the attacker needs (Firesheep).

1. JavaScript-based cryptography cannot be used to construct a secure transport layer.

2. "Tokenize logins": If an attacker is sniffing the traffic, they'll have the plain text username/password and then they can just login with these new credentials. (Replay attack)

3. "Somehow encrypt the transmitted password": After the person has logged in an attacker can sniff the traffic to get the valid session id (cookie) and then just use this instead of logging in. If the entire session was protected with SSL/TLS then this is not a problem.

There are other more complex attacks that affect both this system and our current SSL infrastructure. The SSLStrip attack goes into greater detail. I highly recommend watching Moxie Marlinspike's Blackhat 2009 talk, which lead to the HTTP-Strict-Transport-Security standard.

Since you cannot do SSL at the web server, and you are not a security expert, look for an existing secure authentication service that you can utilize, and let them handle both the SSL and the complexities of handling credentials for you.

In particular, I would suggest that you use a free third-party authentication service, such as OpenID. They have libraries for PHP including one for CakePHP.

---

Edit: (about risks)

While using a 3rd-party secure authentication service (that uses HTTPS itself) can mitigate the problem doing authentication itself without using HTTPS (on your server), it does not entirely eliminate the possibility of attacks.

The most common two attacks would be replay attacks, and session-hijacking where the attacker is able to either re-uses a genuine login session token later, or use a valid session token for their own malicious purpose.

The replay attack can be mitigated by having the session token expiry, and preferably by using a nonce to prevent session replay and to reduces the risk of session hijacking. With a nonce, a legitimate session generates an error if successfully hijacked, because the nonce has expired (been used), so their own session is no longer valid.

If you cannot use HTTPS to encrypt the session token while being transmitted to and from your server, you cannot entirely prevent active attacks such as session-hijacking or man-in-the-middle attack. This may be acceptable in some cases, such as websites with a small user base for non-commercial usage.

The short answer is that without SSL endpoint to endpoint encryption, it's impossible to do it securely...

One of the primary reasons for this is that you can't do secure crypto in a browser. See this reference - Javascript Cryptography Considered Harmful.

Additionally, there's no way that you can be sure that the source of the credentials are indeed who you're talking to. Meaning that there's absolutely no way without SSL to be sure that there's not a Man-In-The-Middle Attack going on.

So no, you can't do it.

Additionally, don't even try. Get SSL. You can get free certificates. Hosts will usually give you a dedicated IP for a few $$$ per month. And if you really care about security, you'd be using at least a VM with a dedicated IP address anyway.

To even attempt this would be Security Through Obscurity at best, and nothing at worst. SSL is a solved problem. Why not use that solution. Security is not something to guess at. Use the proper techniques. Don't try to invent your own. It won't work...

As you suggested, you may be able to generate a unique token each time the page is created. That same token would need to be sent back with the form data and could not be reused. You could also keep the password safe by using JavaScript to hash it, if you can rely on it being enabled by your users.

This scheme is still not secure, however. An attacker could still see everything going across the wire. They could intercept the token and send a response back to you before the user does. Or they could just wait for someone to login, steal that person's credentials (as they are sent over the wire), and just make their own login request later on.

Bottom Line - you need to use HTTPS to guarantee the site is secure.

You can encrypt the password using Javascript and decrypt it on the server.

I would recommend generating an RSA keypair on the server, send the public key along with a timed salt to the browser, then encrypting the password, combined with the salt, using the public key in Javascript.

You can find an RSA implementation in Javascript here

You should include both the IP address and the entire X-FORWARDED-FOR hedaer in the authentication cookies to prevent cookie theft behind proxies.

If you're dealing with sensitive data, you could generate a random AES key in Javascript, then send it to the server along with the password encrypted with RSA.
You could then make the entire application use encrypted AJAX requests from a single page and not use an auth cookie at all.

Note that it is not possible to protect against an active man-in-the-middle attack without SSL. An active attacker can completely replace your site with his own proxy, and there isn't any way to defend against that. (Since there cannot be any known good code)

You can use HTTP Digest authentication, which is supported by most browsers and does not send the password in clear over the wire.

The downside is the ugly log in box displayed by broswer. If you preffer to stick with forms, then you can implement exactly the same protocol as HTTP Digest in your forms authnetication: send hidden fields containing the realm and the challenge, and have the client add in JavaScript the nonce and compute the digest. This way you'll use a well known and proven exhange protocol, rather than roll your own.

HTTP Digest requires only hash operations.

What about HTTP Digest Authentication? It provides security by MD5-hashing username, password and a nonce (among other things) before sending it to the server. MD5 isn't really secure, but it's a good way for simple security with HTTP.

Of course this doesn't prevent hackers from changing the message... but it secures your password.

HTTPS has numerous use cases, most of which are designed to defend against Man-in-the-middle attacks. Anyone with a hacker's mindset will shudder to tell you that there is no way other than the established way to accomplish something. The fact is that just because you use TLS (the standard which modern HTTPS uses), does not mean you are using it well. Additionally, just using TLS does not prevent someone from exploiting known weaknesses. Just as you may be finding creative ways to secure your data, there are people who are finding creative ways to exploit your security measures.

So, what to do?

First of all, if you're going to forego TLS, it is helpful to understand how it works. And it is all about a handshake.

> Once the client and server have agreed to use TLS, they negotiate a > stateful connection by using a handshaking procedure.[7] During this > handshake, the client and server agree on various parameters used to > establish the connection's security: > > - The handshake begins when a client connects to a TLS-enabled server > requesting a secure connection and presents a list of supported cipher > suites (ciphers and hash functions). > - From this list, the server picks > a cipher and hash function that it also supports and notifies the > client of the decision. > - The server sends back its identification in > the form of a digital certificate.[contradiction] The certificate > usually contains the server name, the trusted certificate authority > (CA) and the server's public encryption key. > - The client may contact > the server that issued the certificate (the trusted CA as above) and > confirm the validity of the certificate before proceeding. > - In order to > generate the session keys used for the secure connection, the client > encrypts a random number with the server's public key and sends the > result to the server. Only the server should be able to decrypt it, > with its private key. > - From the random number, both parties generate > key material for encryption and decryption.[contradiction] This > concludes the handshake and begins the secured connection, which is > encrypted and decrypted with the key material until the connection > closes. > > If any one of the above steps fails, the TLS handshake fails, and the > connection is not created.

Source: Wikipedia

So, is it possible? Yes. I was taught that anything is possible. It may be expensive, but it is always possible.

I want to fully disclose that I am NOT a security professional, just an enthusiast. I do not recommend attempting this for a production-grade project or anything other than your own edification. You should DEFINITELY check out this SO post which provides an excellent explanation as to roadblocks in setting up your own security protocol.

However, if you want to move on, here are some thoughts that come to mind. These are realities that will exist regardless of which direct you went with this project.

• HTTPS is supported by all major modern browsers. Even with this reality, HTTPS load times are slower than plain HTTP. Without extensive production, it is highly likely your alternative implementation will be a fraction as secure while being significantly slower. This will be a drawback of any homegrown implementation unless you are utilizing browser features, which brings us full circle back to using TLS, which is what modern HTTPS utilizes.

• If you manage to encrypt your password without TLS on the browser side using Javascript in an unpredictable enough fashion that an MiTM attack would be difficult, don't rest there. You also should be securing the data you send back and forth. Otherwise the password being encrypted really is irrelevant. Sure, an attacker might not know bobsmith109's password, but he doesn't need it, because he can sniff every single activity on the network. He knows what times bobsmith109 logs in, can probably trace his IP, and any other sensitive piece of data you send back and forth.

• No matter what security measures you take, there is security in depth. So one thing that you can do right off the bat is make sure you encrypt your data in the database while also requiring strong passwords.

I reiterate that I am not a security professional and strongly discourage this as anything other than to satiate your curiosity. It is astronomically improbable that you can create a viable alternative to TLS without an extraordinarily large group of security professionals contributing to a project for years if not decades, which is what SSL/TLS can boast. That being said, a good starting point if you choose to go forward is to look at the handshake model above and see how you can implement a version of this without TLS.

I would be remiss to not share in my post that most real-life barriers to using HTTPS are being actively fought against. One of the largest - cost - is very close to becoming a non-issue. A free certificate authority will be coming out 2Q 2015 is supported by some big guns, including Mozilla and Akamai, to name a few. Here is an article.

Login without HTTPS, how to secure?

Since there is no secure channel between your server and your client:

• because there is no secure channel, anybody can snoop your traffic.
• because anybody can snoop the traffic, you are open to a MITM attack.
• because you are open to MITM attack, there is no guarantee you client will see a legitimate page.
• because the pages are not legitimate and your page is in effect not being served (the guy in the middle is serving the pages), all tricks used server-side are rendered useless.

What can you do? Theorically?

• both client and server need to use encryption to make snooping / MITM less susceptible.
• assume you cannot have a handshake,
• assume your client already has your key and knows how to speak the same gibberish as your server.
• how about some SSL over HTTP but wrapped in base64-encoded message for some gibberish?

But wait... Since you said no magic binary, or plugin, not even RSA, I don't know if any of this is possible save for (some potentially very weak) in-house encryption.

--

Create a public/private key pair using an asymmetric cipher.

Create a symmetric key on the server.

Send the public key down to the client side.

Create a random key for the symmetric cipher client side.

Encrypt that random key using the public key client side.

Send the encrypted key to the server.

---

Server does the following:

a. Decrypts the random symmetric key using the private key.

b. Creates a token containing the generated client key.

c. Signs the token.

d. Encrypts the token using the server symmetric key.

e. Encrypts the already encrypted token with the client generated key.

f. Sends the encrypted token down.

---

The client receives this token and does the following:

a. Decrypts the token with the key it generated.

b. Stores the decrypted token.

c. At this point the stored token is only encrypted with the server symmetric key.

---

On every from the client to the server:

a. Encrypt the outbound data using the client generated key.

b. Send the token + encrypted data

---

On every request the server receives:

a. Decrypt the token using the server symmetric key.

b. Verify the signature.

c. Decrypt the data using the client generated key stored in the token.

You can try to replicate it to some point, by using public key encryption (GPG maybe) and making use of browser caching.

>This is not something secure, even just putting up SSL won't be enough for a sophisticated attacker, you need to make use of HSTS, public key pinning etc to just to consider a web site secure today.

The rest of the answer is just food for thought.

1. Create a public-private key pair. Keep private one secure.
2. Create a js file containing the public key and a encrypt function, find a secure encryption algorithm. This function should encrypt a given string (serialized form) with an additional timestamp, to avoid a replication attack.
3. Serve this file with Cache-Control:public, max-age=31536000 HTTP header. We try to mitigate when the attacker tries to replace the script. The file will always be served from the browser cache.
4. Send all the forms via Javascript, using the encrypt function. Serve these with the same header as above.
5. At the server side, decrypt the data, check the timestamp, if it's still valid. Do you thing, if not, discard it.
6. Create a cookie token which can only be used once for a very short amount of time. If the attacker captures a cookie, he won't have much time to do stuff. However, if the attacker is fast enough, then he might log the original user out.
7. Change the cookies with every response. But then what do you do when the user sends multiple requests at once and then they arrive in the reverse order? Which cookie is valid? This creates tons of problems at the cost of a false sense of security.

Any listeners won't be able to make use of the data going back and forth, and they won't be able to change/inject the existing JS files until the cache expires / user clears the cache. However, any sophisticated attacker can replace the whole HTML file which would discard all the security measurements I have just mentioned. If you can at least serve this file / form over HTTPS, you might get away with it, put them on github pages or whatever. However, if you put the file some other domain, then you need to set up CORS for the receiving domain for this to work.

Another try

One time passwords sent to email.

1. User fills out their email, clicks a link which then sends a link to their email with a token that will enable them logging in.
2. User clicks the link
3. Server checks the token, logs the user in.
4. Rolls the cookies like the previous example.

All in all, whatever you do, it is not secure. Given a fast, sophisticated attacker, nothing stands in the way.

Get SSL, if the infrastructure does not support it, change it. If your manager does not believe in SSL, convince him/her. Don't create a false sense of security. Protect your user's data, depending on your location, you are legally required to protect the data of your users.

Then let's talk about how to make a site secure with SSL.

Have a look at "The Secure Remote Password Protocol".

Instead of formulating it myself, let me quote from their webite:

> The Secure Remote Password protocol performs secure remote authentication of short human-memorizable passwords and resists both passive and active network attacks.

and:

> [The] protocol combines techniques of zero-knowledge proofs with asymmetric key exchange protocols and offers significantly improved performance over comparably strong extended methods that resist stolen-verifier attacks such as Augmented EKE or B-SPEKE.

Although the Stanford University doesn't provide implementations for PHP and JavaScript themselves, they link to some 3rd-party implementations.

One of those links leads to "Clipperz", which is an online password manager. It is also available as a community edition on GitHub. There they host their "javascript-crypto-library", which implements the protocol and the "password-manager" itself, which contains backends written in PHP and Python.

I can't say how difficult it would be to extract the relevant portions of code, but maybe you can reuse their implementation (it's licensed under AGPL).

Edit 2014/10/24:

Wikipedia's article on SRP lists some more implementations. Relevant for PHP/JS:

• srp-client (JS)
• srp-6a-demo (PHP/JS)

The best solution I have seen for somewhat secure HTTP connections is to use a Javascript implementation of md5sum (or some other hash) to avoid transmitting the password in plaintext. You can create a form onsubmit handler in Javascript that replaces the password field with a hash of the original value. This adds a modest amount of security to an unsecure connection, but relies on Javascript running in the browser to work properly.

I have the same issue on a system of mine. I have taken steps to try and increase security without compromising the user experience with convoluted mechanisms. What I noticed was that the vast majority of users logged in from the same machine using the same browser, (but not necessarily the same IP address), or from a couple of browsers (eg: desktop or mobile). I decided I could use this to identify a pattern.

1. During registration, users are required to have strong passwords (to prevent dictionary attacks), a security question/answer and standard email verification (as proof of real person)

2. During login, after 5 failed login attempts (not before), a captcha is displayed to prevent brute force attacks.

3. Finally, I created a hash of parts of the user-agent string following a successful login, containing the users OS, browser (general not versions) and language - forming a sort of secondary password. If the useragent hash is significantly different on next login, the user is asked to answer the security question. Then, if this is answered satisfactory, the new UA string is hashed and added to their "safe machines" list, so that they wont be asked again from this machine. This is similar to a mechanism employed by the Steam gaming system.

This has been in use for over a year very successfully with about 700 users and it had the additional benefit of preventing "login sharing" - a problem where multiple users were using the same credentials for convenience!

I guess you care about secure transmission of password to the server? My answer is: dont transmit passwords to the server :)

Infact you may not transmit anything from browser (user) to server to authenticate the user, as an attacker who is spying http traffic would also be able to retransmit the data and authenticate.

Proposal:

Obvious solution would be to use a one-way, one-time transaction authentication originating from server; like a transaction number which can only be used once. Eventually, you still need a secure channel once to sync the list of transaction numbers with user.

You could use something [google authenticator][1], yet you need a secure channel once to setup parameters on either side. If you consider email to be secure, that would be a way to go.

[1]: https://code.google.com/p/google-authenticator/ "Google Authenticator"

The answer is shorter, and if you really matter about security you always have options that different levels of bureauocracy.

Absolut security does not exists. The number one flaw is always on the client side, with trojans ans keyloggers. SSL doesn't help with that.

1. Token generators: banks use them, blizzard uses then. It can be a device or an app. Well.. it's expensive.

2. SMS pins. interesting and affordable solution. There is a lot of good prices from trnasactional sms on the market and everyone has a phone capable of receiving it.

3. If you have to use HTTP, you can force a third party oauth service, like google or facebook. That's the best you can do without a token generator.

Use hashing mechanisms to store password and always compare the hashed password then nobody knows the real password even you. It is very simple but it is effective.However, nothing is completely secure and there are some ways to broke the scurity layers.

If you can't use HTTPS or you don't want to use HTTPS, consider using jCryption. jCryption offers encryption for the data being sent through HTTP requests (POST, GET etc.).

You can test the technique here: http://www.jcryption.org/#examples

If you're using Firebug, you'll see that all the data is encrypted.

It has jQuery library to encrypt the data on the front-end and a PHP library to decrypt the data in the back-end.

Try this : On each request of the login page, send across a nonce and a timestamp. While posting to server, send the following four details :

The username, the nonce and the timestamp in plaintext. Then concatenate the above with a separator (Eg: newline) and encrypt using the user's password as encryption in chained-block-cipher mode.

On the server end use the username to lookup the password and verify the encrypted string.

Since the password is never sent across in clear, it is secure and the timestamp can be used to avoid a re-submit of the same data.

To avoid hijacking of session by obtaining the session key through a man-in-the-middle attack, the password or a hash of the password can be stored in-memory by the application on the client end and be used for generating unique session keys for validation by server.

Taking a look at OAuth 1.0 is also not a bad idea.

It is hard to secure the communication without a trusted third party, however, there are some security tricks for you:

DO NOT expose users' sensitive information to public network.

Every sensitive information should be well hashed or public-key encrypted. Pay attention: If you choose to encrypt users' sensitive information by a public-key, please make sure that the user can verify the public-key. For example, you could send some kind of public-key fingerprint to user via SMS or even an auto-call.

Generate a SHARED SECRET after log on successfully

After a secure log on transaction, a shared secret should be generate. The generation procedure could refer to SSL Handshake. Pay attention: Once the shared secret is generated, it must on be transported anymore. The only function of it is to encrypt/decrypt the data between Server and Broswer

There SHOULD be a two-step-verification to avoid repeat attack

May these tricks will help you