In the authentification page the user writes his password, and if it is correct, he is redirected to the main page.

In the main page there is a messenger also, which uses end-to-end encryption (Diffie- Hellman and AES). For that, it requires the password of the user to generate a key (for Diffie-Hellman).

I don't want to ask the user the password again. However I don't know how to send the password from authentification page to the main page securely.

May I save the password in coockie, get it in another page as redirected and delete it?

  • you can pass it along the url's hash, which is not routed over the network. – dandavis Aug 23 '16 at 20:20

First of all, storing passwords client side is a big no-no, because they are available as plain text, your site is insecure by design if you do this.

What you should do is try to find mechanisms to get the keys you need, for example on login you not only authenticate the user but you also generate the Diffie- Hellman key for the messenger and you store it in a Session Variable, you can retrieve it later on when needed.

The password should only be used in most cases to generate a secure hash in order to verify the identity of the user against a database after login in, it should never be stored or transmitted in plain text.

If you provided more details about the technologies we could give you more examples related to your specific situation.

| improve this answer | |
  • I can't store the Diffie-Hellman key in a SESSION, because if MitM gets it, he would decrypt all messages. I need the Diffie-Hellman key generated on client side, and encrypt all messages on client side. – Sonya Seyrios Aug 22 '16 at 14:45
  • 1
    You store the key in a server side session variable, and you transmit it to the server using TSL, so your chances of MiTM are very narrow, standard practices are better than reinventing the wheel in security. – Freddy Ayala Aug 22 '16 at 14:51
  • I don't have SSL/TSL. That's why I don't want to send Diffie-Hellman to the server. It would be much safer to store it in coockie and delete it as got in other page. – Sonya Seyrios Aug 22 '16 at 14:55
  • 1
    Both schemes are unsafe, either storing locally in a cookie or transmitting in plain text are the same, your password could be recovered via an XSS attack if you store the password in the cookie. Furthermore, it might be far more feasible to perform an XSS than a man in the middle attack. If you don't have the resources to have proper security, you need to do a risk analysis and create complementary controls and assume the risk,so in this case (even if not recommended) if you decide to store the password you would have to encrypt it in some way, never store or transmit passwords in plain text. – Freddy Ayala Aug 22 '16 at 16:14

Just use TLS, please. Trying to roll your own security like that is a recipe for disaster. Really. As Scheiner law goes any person can invent a security system so clever that she or he can't think of how to break it. Even if you were a smartest of all cryptographers ever alive (in which case you really wouldn't be asking), it is unlikely you'd get it right -- it took decades for hundreds of smartest of them to come up with TLS, and it still has rough edges.

So, if you want a chance at making it secure, use TLS (as shown in this and previous question comments). Even just using TLS securely without exposing yourself to dozen attacks (side channel, xss, etc) is hard. Without it, it is pretty much impossible. And if security is not really your goal, then just obfuscate it with ROT13, or Base64, or XORing with hardcoded password or some other quick and easily crackable scheme and get it over with - at least you won't be lulling yourself with false sense of security.

| improve this answer | |
  • You're talking about TLS just like it's something from another planet. The TLS uses known algorithms, such as Diffie-Hellman, RSA etc. I don't have TLS, and don't want to buy it. Probably, you know another way of getting TLS? – Sonya Seyrios Aug 22 '16 at 19:48
  • It is way more complicated than you seem to think (which is another reason to avoid roll-your-own security). It is enough just to read about few recent years of exploits in SSL2, SSL3, TLS1 etc. to get the idea. You can get HTTPS certs for free, for example letsencrypt.org or startssl.com – Matija Nalis Aug 22 '16 at 19:59
  • The problem is, the page is in a private network. How would I certificate it? – Sonya Seyrios Aug 22 '16 at 20:02
  • There are instructions on each CA. For startssl for example, you generate certificate request, copy/paste it and get certificate which you copy/paste back on server. For letsencrypt, you run a script with appropriate parameters. Just read their instructions, really. – Matija Nalis Aug 22 '16 at 20:09
  • @SonyaSeyrios While TLS does use known algorithms, it is backed by an extensive certificate authority infrastructure to protect against MiTM attacks. Rolling your own, you have no defense against them, not to mention all of the other implementation errors that could arise. – tlng05 Aug 22 '16 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.