Why don't you just post it? Seems like fair use to me.

How could you tie the OTP to the website using Trustbar? I see that Trustbar can solve the SSL problem of host identification, but I don't see how it could meet RSA's goal.

Nick,

I think there are some plugins that just manage passwords on a per-site basis. Whereas Trustbar manages names on a per-cert/site basis. I.e., Trustbar doesn't manage the user-auth-to-site leg, just the site-auth-to-user leg.

This is all open to question and interpretation of course, but I think in terms of their claim that "the user wants the same level of assurance that he's dealing with the right/trusted site" this is an area that the petnaming concept covers well.

TrustBar can help the user identify the real, SSL/TLS protected site, thereby sending the password - or OTP - securely and preventing the threat.

The solution that RSA described, using the site's URL as input to the challenge-response device, will work for OTP devices but not for passwords (which will still be subject to dictionary attacks). BTW, the binding should preferably be to the site's public key, imho, and not (just) to the URL, to protect against DNS poisoning and other MITM attacks (e.g. on shared media LAN such as wireless). But if you enter your password (or - better yet - OTP / response from gadget) into an SSL/TLS protected site using the correct public key, as assured by TrustBar, this is even better.

OTOH, TrustBar still depends on users noticing spoofed site. It is much easier to detect spoofed site with TrustBar, which displays your chosen name or logo for the trusted site (or at least the certified site's name or logo and identity of CA). But, many users may still fail to notice the spoofing. We hope this will substantially improve with our new version, which will try to implement my new moto: `defend, don't ask`. When user clicks on his bookmark for his sensitive sites (bank, etc.), we'll take him to that page - but only if it is the correct page. This will also protect users of these shameful unprotected login pages.

Good point, Ian. I vaguely remember now seeing something about a passkeep extension? I'll have to research. And I agree that petnames/trustbar assure the users that they are at the right site.

Amir: We bind to the public key by downloading a hash of the sites cert from the the OTP server along with the OTP. The token client then gets the cert from the internet, hashes and compares the two. We then launch the browser to the correct website for them and provide the link with an OK message. So, we also work for OTPs, but only our own and not passwords. We don't have a browser plug-in, yet ;).

As for shameful: in testing, I entered https://www.bankofamerica.com into the test server. Everything worked great, the browser launched to https:/www.bankofamerica.com, and was then redirected to the http page for login!

I would really like to see form-based authentication go to the deepest pockets of hell, where it really belongs. HTTP AUTH is an existing better alternative, except that browsers do not distinguish between BASIC AUTH and DIGEST AUTH. The former must be disabled by default an be visually different even when enabled.
Further authentication mechanisms, such as SRP and RSA-signature of requests with password-derived private keys could be added to futher improve security.

There's nothing wrong with entering login information into a form on an HTTP page provided the underlying Javascript submits the data to a HTTPS URL (as does the Bank of America site).

I agree though, to the untrained eye it would appear to be an insecure login prompt. My bank has two login pages; one page that does this and another that provides the form from an HTTPS URL. I prefer the latter.

Piers,

I'm afraid there is something wrong with entering the info into an unprotected HTTP page! It is not with that immediate session but with future sessions that the problem arises.

In short, using unprotected HTTP pages is training the user to be phished. If I can get you onto a page that is unprotected and looks like your bank, then when you enter you username and password, it matters not what happens after - You've still been phished.

(Don't worry, this wasn't obvious to me until we'd beaten it around with 10 or 20 loud emails :)

(And, the fact that this site permits you to post comments on both HTTP and HTTPS is training for phishing... luckily the details you enter in aren't as valuable!)

The company called RSA is really the old Security Dynamics business rebranded. They have a big base in OTP deployments and have made negligible impact on the PKI market despite their name. They are currently seeing their margins eroded as their patent portfolio expires and the tokens are becomming a commodity.

Although RSA regularly features highly in the Netcraft CA vendor surveys these certificates are actualy sold by VeriSign, not RSA. The certificates sold by RSA are actually issued off a GeoTrust root.

I think you're misreading the white paper. RSA just bought Cyota, a company that makes systems for authenticating end users. They offer products that authenticate users and web sites without using OTPs or certificates. It looks like this is more of a rebranded white paper from the Cyota folks (which would, of course, badmouth OTP and certificate based systems) than a large change in RSA's position.