268835 - enable authentication that is secure against phishing

Status: RESOLVED DUPLICATE of bug 1065729

(Core Graveyard :: Security: UI, enhancement)

Description

[Ralf Hauser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041024
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041024

DH-EKE (Bug 233836) is a big step forward in password security, but it doesn't
solve the most stupid attack, namely the attacker using javaScript to pop-up a
similarly looking window than the one they propose in figure 2 of their paper an
fool the user to transmit the password the phisher in this way.

In order to really overcome the problem I think two more parts than just the
password will be needed in the future:
1) the user's IP address and
2) the user SSL session ID (I haven't really studied whether a man-in-the middle
can determine that ID, but I assume if s/he can, it's either for the connection
FROM the user or the one TO the bank, but not both).

So this is how the idea works:
a) the user gets a challenge-response device, i.e. a security token with
keyboard from the bank to enter the password (e.g. like RSA secureID). In
calculating the response, the device also enters the user's IP address and the
SSL session ID.
b) when receiving the response, the bank also needs to hash in the session ID
and the IP in order to validate it. If there is a mismatch, the session needs to
be restarted because there might be a man-in-the-middle. 
The SSL session ID is needed because the man in-the-middle could send packets to
the bank with the forged user origin IP and attempt to blindly loot the bank
account.

Since javascript could also forge mozilla pop-ups that inform about the current
IP and SSL-session ID (and copying them manually isn't feasible for the end-user
anyway) - these two numbers plus the challenge would have to be transmitted via
USB/Bluetooth/... to that security token and not by the human.

Why am I posting this to mozilla: Albeit not being aware of a security token
already implementing such a protocol, for it to work, the browser/mail-client
needs to have an interface where it hands off these values to such a security
token and that's what this RFE is asking for.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




arguments against this are: 
1) If one is going through all the trouble of connecting a device to the
user-agent, why not just use client certificates? Not being a specialist of
client certificates - the following counter-argument comes to mind:
When the user looses the private key, off-line guessing attacks can be run
against the device. In comparison, when loosing a challenge-response type device
- the bank is an online authority that can prevent such guessing attacks.
2) with increasing numbers users not having a fixed IP, success rates of
authentication may be reduced due to false rejects when the dynamic IP happens
to be changed just in the course of the authentication process by the ISP.

Comment 1

[Ralf Hauser]

hashing into the response some biometric info (e.g. fingerprint when operating
"the calculator") is yet a higher level of security

Comment 2

[Ralf Hauser]

just FYI - tomcat can get at that SSL session ID easily
http://issues.apache.org/bugzilla/show_bug.cgi?id=22679.
Also, RSA doesn't appear to have a relevant product yet, but they appear to be
working on improved phishing protection in their labs.

Comment 3

[Ralf Hauser]

one correction: if the client can choose the SSL-Session ID, a phisher can
observe the ssl session ID received from the banking user, and then use the same
with the bank.

Thus, after correct authentication, the bank would have to force immediate
re-SSL-handshaking with the IP in the auth-response to kick out the phisher.

Comment 4

[Ralf Hauser]

If the hardware device shall also protect against hijacked DNS of the end-user's
ISP, it will need also:
- root certificates
- a clock (although this normally present in simpler versions of such a device too)
This way, the timestamped challenge can be signed by the bank server and the
device would detect if an illegitimate fake bank server that appears to be on
the right memnonic address due to the subverted DNS sends a false or replayed
challenge.

If the device instead of hashing with a shared key of the bank were to encrypt
the authentication response with the public key of the bank, the problem of
"paypal" vs. "paypaI" is back again. Thus, especially if multiple institutions
wanted to leverage the same device, some kind of trusted path (e.g. a button for
"my bank", another one for "my accountant", etc.) would be needed.

Also, it would be interesting, whether such a device could emulate such a
protocol with the PKCS11 API or alike.

Comment 5

[Ralf Hauser]

Two more ideas if the device were non-galvanic but had a high bandwidth receiver
and a screen (e.g. a scanner such as the http://www.axsionics.ch):
1) After authenticating, the e-banking user can enter all the transactions etc.
2) Unless the user does a 2nd sign-out authentication that also shows a
transaction summary on the trusted device, none of the orders will berall be
executed.

Pros: - very simple
Cons: - a phisher still can see the account content
      - the users today are not used to late committ/roll-back. Initially 
        support cost (and user frustration about non-executed transactions 
        because they just closed the window instead of proper sign-out) will be 
        bery high
      - server-side complexity in order to be able to fully roll-back is quite 
        high

Comment 6

[Ralf Hauser]

Another approach based on a http://www.axsionics.ch -like trusted device could be:

At the end of the authentication, the device shows on its screen a new URL that
then will be used to open the eBanking the session. The user copies that
https-URL into his browser and starts an entirely new session.

Pros: - If the end-user properly copies the URL, the phisher has no chance 
        (under the assumption the phisher does not control DNS/the routers 
         surrounding the end-user)
Cons: - how would that be done?
        https://RANDOM.bankdomain.tld or https://www.bankdomain.tld/RANDOM  ?
        If there is any chance that the user might not entirely type in the URL
        from the device's screen, there is the risk that the phisher-url will
        be taken to alter the RANDOM part. If that happens the phisher is back
        in business...
        
So, besides some usabilty concerns, there is the risk that the cure is
susceptible to the same attack as everything before?

Any other thoughts how this creative approach could be done better?

Comment 7

[Ralf Hauser]

the basic idea of how to make a security device personally transferrable and
still provide good authentication (there even without a galvanic or aequivalent
UA-device connection) is 
http://www.zurich.ibm.com/security/publications/1993/MT93.ps.gz ([MT93] in
http://www.zurich.ibm.com/security/publications/1993.html)

Comment 8

[Ralf Hauser]

some ideas by RSA, but few hints how to implement this with current
browsers/MUAs or what needs to be changed
http://www.rsasecurity.com/newsletter/Vantage/Fall2004/Fall2004/rsalabs.html 

FYI also a link to educate your users

Comment 9

[Ralf Hauser]

see Bug 322661 for an approach against MITM that requires no changes to the underlying SSL/TLS protocols requires almost no changes to the browser

Comment 10

[Martin v. Löwis]

This seems all pretty hypothetical, so I suggest to close this report.

Comment 11

[Ralf Hauser]

hopefully, this will become a lot more concrete in March after http://www.w3.org/2005/Security/usability-ws/cfp.html .

Another interesting approach is SRP (http://srp.stanford.edu/)

Comment 12

[Steffen Schulz]

https://bugzilla.mozilla.org/show_bug.cgi?id=405155 implements TLS-SRP, an extension to TLS that enables mutual authentication based on user passwords.

The implementation lacks a user interface for mozilla/firefox. The client needs provide a (spoof-resistant) login dialog and supply the entered credentials to SSL.

After spending some time with NSS, I'm again altogether new to the code that handles SSL. I was hoping to find someone who is familiar with it to finish the implementation of the protocol. Or someone motivated enough to try it with me.

Comment 13

[Steffen Schulz]

Are there any suggestions for the UI? Making it spoof-resistant is not trivial. The current and future htaccess dialogs for example should be trivial to spoof via flash. Also, this dialog should be obviously different from the htaccess and webauth dialogs to indicate to the user that a secure login-method is used.

My suggestion is to 'attach' the dialog to the urlbar, even merge it partially.
There could be a window much like 'Larry' in FF3 extending to the length of the urlbar. The user is then expected to type his username in a field that is placed front of the domainname in the urlbar. Depending on details, certificate-information may become available before the password is needed, in this case the dialog should be dynamically enriched by certificate-info and a field to enter the password. Larry could be part of this window to indicate the sec-status.