password submitted in clear text?

[demianturner]

Apologies if this is not the right category. I am not a sysadmin but I would like to resolve an issue that a few sysadmin friends disagree on.

If you enter your username/password details in a web form over a non-ssl connection, ie, http://mysite.com/form.php, is it not true that the details are passed in clear text to the form target? To me the answer is a pretty obvious yes, but one friend argues that because the target is https://mysite.com/formtarget.php that the data is sent via a secure socket, in other words encrypted and securely.

The page in question is my bank, http://www.ebankinter.com/ which is why I'd like to get to the bottom of this. The bank of course claims the connection is secure but I think they are mistaken. Let me point out that:

- there is no client-side javascript MD5 hashing of the password
- there are no challenge-response token being sent

The bank claims something about java applets but viewing the source you can see this is nonsense. You can also view the included js and see nothing other than form focuses being called.

http://www.ebankinter.com/www/es-es/scripts/utils.js

I look forward to hearing peoples comments.

cheers

Demian

[xipe]

Yes, the data is submitted securely. The form is printed in plain text, but when you fill it up and submit it, it will be delivered via secure connection.

[HarryF]

Fairly sure as well that it's submitted securely. Think the process is like this;

1. The form is downloaded to the client, using an insecure connection.
2. The user fills in the form and clicks submit.
3. The browser sees the target URL begins https:// so first establishes an SSL connection to the server
4. The browser sends the form post to the secure socket, so the submitted details are encrypted

That's pretty much what happens when you login to the Sourceforge website and I'm sure there'd be a riot if it was insecure.

That said, that banks (and my own bank does it!) even bother with JavaScript hacks like preventing View > Source suggests the fundamental strategy is security by obscurity which often means there's a hole in there somewhere

From a quick look at ebankinter's site with LiveHttpHeaders, it looks like they send a session cookie before you're logged in.

OWASP had an interesting article (somewhere) about a session hack called something like "pre-hijacking" which works like;

1. The attacker visits http://www.ebankinter.com/ and gets a session ID
2. The attacker tricks a legitimate bank customer's browser into using the session ID (may be by just posting a URL if the remote site accepts session IDs that way) and gets the user to visit the bank site and login.
3. Once the customer has logged in, the attacker knows the session id they are using and can hijack the session.

If you're using ebankinter, suggest using LiveHttpHeaders to watch the value of that session cookie - hopefully they change it as you log in...

[Hierophant]

Hmmm my bank (Bank of America - www.bankofamerica.com) does something similar on its homepage.

However, the login form is never submitted to the bank's server. When you click on the "Sign In" image, your inputs are encrypted using Javascript and written as cookies. Then since the "Sign In" image is a simple link and not a form submit button, it loads the next page which is on a secure server, loads the previously encrypted cookies, decrypts them and checks your credentials. They also have two session ids that they use. One in the URL and another which is created by the login form and stored in the cookie based on the original session id. I guess this is to secure against the "pre-hijacking" mentioned above.

When I first saw the way they were doing things, I was a little concerned as well. Took me a couple hours to decipher the javascript and now I do all my banking through their web-based interface. It is more secure than writing checks and putting them in the mail.

[demianturner]

hi W. Luke

i checked the boa page, this is much more like what you'd expect from a bank, as I mentioned in the original post the ebankinter folks appear to have a security lapse. Thanks for your comments, I think i will point the bank's IT staff to this post ;-)

cheers

demian

[demianturner]

Finally got the time to install a packet-sniffer (EtherDetect Packet Sniffer from tucows.com) and it looks like the folks at bankinter, who I suggested were allowing customers to send user password data in the clear, were right when they said that confidential info was only sent via secure sockets.

The following info is what I discovered:

1. Logging onto a non-SSL site from a non-SSL url, taken from the Seagull project, the first packet sent from the client to the server arrives at port 80 as a POST and looks like this (from the demo which has a public logon):

---------------------------

POST /**UnReg** HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
Referer: http://seagull.phpkitchen.com/login.php?PHPSESSID=78f599ef026f2fa1fb6a2b8ad0d84b0a
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: seagull.phpkitchen.com
Content-Length: 53
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PHPSESSID=78f599ef026f2fa1fb6a2b8ad0d84b0a

frmUsername=seagull&frmPassword=admin&frmSubmit=login

---------------------------

2. Logging onto an SSL site from a non-SSL url, taken from a bankinter logon, the *first* packet sent from the client to the server arrives at port 443 and as it is encrypted from the time it leaves my client this is what you get:

---------------------------

[an SSL handshake which involves the exchange of about 10 encrypted packets]

....J.**UnReg**
u|Ul�sU

[ ... gibberish ...]

[then the main data, also obviously encrypted]

«ÍðêïÔ**UnReg**÷TNð룥‰Úü..Ò+ðÚŒ#.Ñ"ã4=.¸.ŒÎ

[ ... more gibberish ...]

---------------------------

3. Logging onto a non-SSL site from a non-SSL url, taken from the PHPclasses which uses clientside javascript md5 encryption, the first packet sent from the client to the server arrives at port 80 as a POST but as the logon credentials are encrypted before they leave the client, they arrive securely looking like this:

---------------------------

POST /**UnReg**l HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
Referer: http://www.phpclasses.org/login.html?page=
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: www.phpclasses.org
Content-Length: 129
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PHPClassesSession-remember=xxxxxxxxxxxxxxxxxxx; phpAds_capAd[95]=1; phpAds_capAd[86]=2; phpAds_capAd[31]=2; phpAds_capAd[85]=2

alias=demianturner&password=&submit_button=Login&remember=on&dologin=1&user_lo gin=654ba6545e45d654c65446ee56465bb65&session=&page=

-------------------------

The user_login token is made up for the sake of an example :-) Thanks for those who contributed to this post.

cheers

Demian

[demianturner]

And finally ....

just to answer Harry's question above, yes Bankinter does correctly change the session cookie after logon :-)