Save password cookie as MD5 hash [DENIED]

[jakk]

Currently the password cookie is saved as plain-text (tip for anyone who forgot their password and has the auto-login feature enabled: check the password cookie)

This could be a security flaw, as the password goes unencripted and anybody could intercept the http request and easily discover the password.

My suggestion is to save an MD5 hash of the password in the cookie (use javascript for that)

This would imply also changing the code of the login form, instead of sending the plain-text password, the form would have to crypt the password before sending it.

PS: I'm assuming the passwords are saved as MD5 hashes on the AniDB database

[exp]

actually the only problem the current solution causes is that a local attacker has access to your password in plain text.

however as the autologin function is only meant to be used on trusted pcs that is not a big issue.

about the password going unencrypted over the inet connection, well that is a basic issue you have on ALL websites which do not use SSL encryption.
i.e. ebay does it by default, but does anyone complain?
and i am sure that the damage of a stolen ebay account is far greater than of a compromised anidb account.

in short, i might store the local auto-login cookie as a random string token instead of the password some day, but the normal login will still send the password unencrypted.

BYe!
EXP

[Skywalka]

just a small hint: you can login to ebay using ssl but since that feature causes a popup window on many browsers (= internet explorer displays a small ssl message) and that might irritate the non-computer-buffs (= DAUs = dümmster anzunehmender user = most stupid user possible = SUP ) eBay chose to deactivate it/make it non-default.

So everybody with half a brain cell should look for the ssl-login on the ebay website. With all the eBay identity fraud and the password phishing around there really should be a change in eBay's policy but then again they still do everything to keep the powersellers happy and those add their items via additional programs to eBay.

But I got carried away

On a sidenote I really wonder who'd want to access my anidb mylist. I mean it's just a list of hashes for files I might have or not have somewher

[exp]

just a small hint: you can login to ebay using ssl but since that feature causes a popup window on many browsers (= internet explorer displays a small ssl message) and that might irritate the non-computer-buffs (= DAUs = dümmster anzunehmender user = most stupid user possible = SUP ) eBay chose to deactivate it/make it non-default.

So everybody with half a brain cell should look for the ssl-login on the ebay website. With all the eBay identity fraud and the password phishing around there really should be a change in eBay's policy but then again they still do everything to keep the powersellers happy and those add their items via additional programs to eBay.

But I got carried away

On a sidenote I really wonder who'd want to access my anidb mylist. I mean it's just a list of hashes for files I might have or not have somewher

totally OT:
last thing i heard was that they did it in order to lower their server load.
(and http <=> https DOES make a huge difference in server load)

BYe!
EXP

[jakk]

On a sidenote I really wonder who'd want to access my anidb mylist. I mean it's just a list of hashes for files I might have or not have somewher

It's not about getting access to your mylist. It's about knowing your password. Many people use the same password for lots of things, like email accounts, homebank accounts, etc etc.

Anyways, if you encrypt the password on the client side, the only thing that goes on the wire is an encrypted string, which is somewhat difficult to decrypt as MD5 is a one-way function.

SSL is not really required, because you don't want to encrypt the whole data that is sent, just the password.

Here's a sample of the HTTP request that goes through the wire. A remote attacker could intercept this.

Host: anidb.ath.cx
User-Agent: ELinks/0.9.2rc1 (textmode; Linux 2.4.22-28mdk i686; 80x11)
Referer: http://anidb.ath.cx/perl-bin/animedb.pl
Accept: */*

Accept-Encoding: bzip2, gzip
Cookie: adbsessuser=your username; adbsess= session string; adbautouser=your username; adbautopass=your password here

[exp]

It's not about getting access to your mylist. It's about knowing your password. Many people use the same password for lots of things, like email accounts, homebank accounts, etc etc.

blame them, not us

Anyways, if you encrypt the password on the client side, the only thing that goes on the wire is an encrypted string, which is somewhat difficult to decrypt as MD5 is a one-way function.
SSL is not really required, because you don't want to encrypt the whole data that is sent, just the password.

just encrypting the cookie doesn't help much. you'd need to send the initial password the user enters in the password form too.
and for resulting md5 hash to be usefull the client would need to use the same seed as the one used for the md5 hashed password in the server database.
so we'd have to add a seed to the login form and the browser would need to md5 hash the password with that seed before submitting it.
i doubt that any webbrowser supports something like this out of the box.

BYe!
EXP

[jakk]

http://pajhome.org.uk/crypt/md5/

here you have a javascript (clientside) implementation of MD4, MD5 and SHA-1 encryption (BSD License)

[exp]

http://pajhome.org.uk/crypt/md5/

here you have a javascript (clientside) implementation of MD4, MD5 and SHA-1 encryption (BSD License)

i am talking about native support on the client side.
using java script for the login would prevent all the ppl who deactivated javascript from loggin in @ anidb.

however, we might think about including something like this as an additional option, the default would still be to send the password in plaintext though.

BYe!
EXP

[jakk]

A way to do that without javascript (but a little less secure):

1) Client checks the remember login checkbox and logs in.
Password is sent to the server in plaintext

2) Server encrypts password and responds to the client with a setCookie with the encrypted password

3) Next time user accesses the anidb, server will check if there's the autopass cookie with the encrypted password

This only makes it a little more secure for those who use the autologin feature, as their password only goes in plaintext once and is locally stored encrypted

[exp]

A way to do that without javascript (but a little less secure):

1) Client checks the remember login checkbox and logs in.
Password is sent to the server in plaintext

2) Server encrypts password and responds to the client with a setCookie with the encrypted password

3) Next time user accesses the anidb, server will check if there's the autopass cookie with the encrypted password

This only makes it a little more secure for those who use the autologin feature, as their password only goes in plaintext once and is locally stored encrypted

which would be more or less what i suggested in the beginning:

in short, i might store the local auto-login cookie as a random string token instead of the password some day, but the normal login will still send the password unencrypted.

BYe!
EXP

[Elberet]

Besides, MD5 is not an encryption. It's a hash. The MD5 checksum of one string is always the same. If you send the password hash instead of the actual password, an evesdropper who catches the hash doesn't need to know the cleartext password. Sending the hash will be enough.

For real security, you will have to use SSL or some other method of safely encrypting the whole communication between AniDB and the browser, and that is neither feasible nor inexpensive and costs quite some CPU power.

One approach that is fairly easy to implement and avoids to send an identical string over the network repeatedly is this:
- All login transactions are handled via a separate subdomain, such as login.anidb.ath.cx.
- Upon login, create two tokens: A normal session cookie and a relogin cookie. The session cookie expires at the end of the browser session, and the browser is instructed to send this cookie to anidb.ath.cx, all subdomains and all paths. The relogin cookie is stored permanently, but the browser is instructed to only send that cookie to login.anidb.ath.cx and path /perl-bin.
- A session is terminated after 2 hours of inactivity or when the client's IP address suddenly changes.
- When a session is terminated, the user is redirected to a relogin script on the special subdomain. This script, unlike all others, sees the relogin cookie, validates it and performs the normal login procedure, setting a new relogin cookie and starting a new session.

[exp]

For real security, you will have to use SSL or some other method of safely encrypting the whole communication between AniDB and the browser, and that is neither feasible nor inexpensive and costs quite some CPU power.

yep, using https is definetly not planned for anidb.

One approach that is fairly easy to implement and avoids to send an identical string over the network repeatedly is this:
- All login transactions are handled via a separate subdomain, such as login.anidb.ath.cx.
- Upon login, create two tokens: A normal session cookie and a relogin cookie. The session cookie expires at the end of the browser session, and the browser is instructed to send this cookie to anidb.ath.cx, all subdomains and all paths. The relogin cookie is stored permanently, but the browser is instructed to only send that cookie to login.anidb.ath.cx and path /perl-bin.
- A session is terminated after 2 hours of inactivity or when the client's IP address suddenly changes.
- When a session is terminated, the user is redirected to a relogin script on the special subdomain. This script, unlike all others, sees the relogin cookie, validates it and performs the normal login procedure, setting a new relogin cookie and starting a new session.

I don't see the benefits of that aproach, at least not enough of them to make it worth the time it would take to set it up.
compared to using randomized relogin cookies which are always transfered that is.
If you send it over the wire in every request or once every 2h doesn't make a noteable difference under security aspects. IMHO

BYe!
EXP