Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Password Encryption , storing password in session

I am in need of storing password and use it again. I think this is not at all safe.

Scenario:

I want to create a webmail program where user login with username and password, then check their emails. This tool does not intend to store passwords on db. But in PHP we need to connect to the mail server in each page the user navigates to. So username and password is needed to connect to mail server. How can this be done in the safest way?

like image 743
Kiran Avatar asked Jan 12 '13 13:01

Kiran


People also ask

Is it okay to store password in session?

Yes. You can choose to store your derived key in the session knowing it might be compromised if the server is compromised, but at least the users's password is still safe. That way your security failure doesn't become a much bigger problem for users who use the same password elsewhere.

How are encrypted passwords stored?

Passwords are encrypted by the SHA-1 encrypting algorithm before they are stored in the directory. Passwords are encrypted by the Salted SHA-1 encrypting algorithm before they are stored in the directory. Passwords are encrypted by the SHA-2 family of encrypting algorithm before they are stored in the directory.

Do session Cookies store passwords?

It's NOT secure to store passwords in cookies because they are available as plain text. Indeed. It is never secure to store passwords anywhere.

Where is the encrypted password stored?

Each user's password is stored in an encrypted form within the /etc/passwd file. These credentials are hashed using a one-way hash function so they cannot be decrypted.


1 Answers

Since storing the password is not intended, but also having to re-enter the password many times is not desirable either, the only solution I see is this:

  • Encrypt the password (using e.g. AES) with a random key of sufficient length
  • Store the encrypted password and username in the session
  • It's probably no mistake to encrypt the username and mail server too, just in case. It won't hurt, and a presumed attacker doesn't have a known username on a server.
  • Store the encryption key in a cookie

This is not perfect, but it should work reasonably well, and it is probably as good of a trade-off as you can get.

With each request, the user's browser will send the cookie, the PHP script can use the cookie to decrypt the data stored in the session and do a request on the IMAP/POP server.

Someone exploiting your server and gaining access to the session store will be able to steal encrypted passwords, but if your random keys are of sufficient length and good random quality, this is pretty futile.

The point is, you can only really secure something with a secret that you don't know. If you have the necessary information to decrypt some information (IMAP password in this case) on your server, for example in the session store, everyone exploiting your server can do the same. No matter how strong your encryption is, it doesn't make any difference.
The only way to make sure secrets remain secret is by encrypting them with something you don't know, something only the user (or in this case the user's browser) knows.

Which leads to the unsolvable problem that at some point in time, you obviously have to know, at least for a fraction of a second. That's the time between the web server receiving the cookie and the PHP script exiting. In theory, if someone with root access was reading the process memory during that time, he would know the secret, too. But alas, that is something you really cannot prevent.
As long as the information is never stored anywhere (not even in the session) it should be reasonably safe, though.

Of course all of this assumes that at least the login page on your site (preferrably all) is served via https://, and you use TLS/SSL to communicate with the mail servers. Otherwise, you're open to much more trivial attacks.

like image 128
Damon Avatar answered Sep 23 '22 15:09

Damon