hashing into the response some biometric info (e.g. fingerprint when operating "the calculator") is yet a higher level of security
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.
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.
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.
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
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?
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)
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
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
This seems all pretty hypothetical, so I suggest to close this report.
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/)
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.
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1065729
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.