Password security issue

Kai-Marian Pukall

•

Hello, since I had forgotten my password for this site, I recently went through the process of regaining access. I was shocked to see that, apparently, your website was able to retrieve my password (in plain-text) and send it to me via e-mail. As a computer scientist with web design experience, I feel the need to inform you that this is quite a security issue. Besides sending the user a password unencrypted which he/she might be using on several other websites, I find it unsettling that you seem to keep user passwords in plain-text in your database, meaning that anyone with access to your servers (or anyone that happens to be sniffing traffic at the moment your password reminder e-mail is processed) might be able to use the user's profiles on other websites as well. To remind you, the standard approach to password security is the following: *NEVER* save the user's password in the database. On registration, create an md5 hash (or similar) of the password and insert into your database On login, create an md5 hash of the user's password and compare to the one in your database If the user has forgotten his/her password, randomly generate one, send that via email and save an md5 hash of the randomly generated one in your database. Since the password was transmitted unencrypted, the user MUST be requested to immediately change his password to one only known to him. Since it is computationally hard to retrieve a character string from its hash, this approach increases website security greatly. You being unaware of this issue suggests you may not know about a wide field of security risks, so I would like to recommend reading a few practice-oriented books on common attack schemes like XSS or SQL injection. Sincerely, Kai

5 replies

JUMP TO THE LATEST POSTS

Carl-Ola Bostroem

•

are you serious?? that is shocking. immediately changed my password

Jarmo Annunen

•

Epic megafail.

Kai-Marian Pukall

•

Some users have approached me with concerns that posting this issue in a publicly available forum might have made matters worse by informing potential attackers about this. If this was that big of a risk, I would have contacted the site admins over a more private channel, I can assure you. As long as database access is secure (I trust that is the case?) and noone with access to the database has plans to use the information in an harmful way, there should not be any immediate danger to your personal data. IT security experts do not recommend using the same password for multiple services, anyway! However, I think the issue here is trust - by using a service such as this one, users assume that the site administrators will (1) keep only as much personal data accessible as absolutely necessary and use it in a responsible way, and (2) make sure that the service itself cannot be used to attack users directly via cross-scripting attacks, SQL injection or similar techniques. Personally, I see some work that needs to be done on issue 1, I have not checked for attack possibilities similar to point 2 (and would surely not discuss them in this forum if I had found some). Admittedly, I am not an IT security expert in any way, but from what I know about implementing and maintaining a website with any kind of login feature, this is a point that I would like to see addressed as soon as possible.

Robert Andersson

•

You may have noticed that no 8a.nu pages are sent over SSL (https) anyway, so passwords are sent in plaintext on every login, and therefor available for any sniffer. I'm all for neat security and stuff, but also think it should be in proportion, and also that it is to some extent the responsibility of the user to verify the level of security. There is very little to gain for anyone to "hack" 8a.nu-accounts, compared to the effort to do so. You should never trust anything, so you should never share your password for different applications, unless you don't care much (which sometimes is a valid approach). I don't care much if someone found my 8a password; all that would give them is access to my score card and maybe post something on the forum, and potential access to a few other non-important sites, all of which is easily rectified. Sorry about the rant, I just felt the need to talk a bit :) You are of course right in principle, but I thought I would inject some perspective.

Kai-Marian Pukall

•

That's correct. However, you'll agree when I state that it's probably more difficult to sniff data that may or may not be sent at intervals of perhaps around once per day, than to access data in a database waiting to be used. Even if a user's password is sniffed, that's only a single one and not a pile of over 10000. What really concerns me, however, is that this is such a standard issue that it should not happen at all! This looks to me like careless design and makes me wonder in what other ways this service is vulnerable to exploits.