Hacker News new | comments | show | ask | jobs | submit login
London Calling: Two-Factor Authentication Phishing from Iran (citizenlab.org)
55 points by secfirstmd on Aug 27, 2015 | hide | past | web | favorite | 21 comments



Google already has a solution for this, why are they ignoring it?

Google allready supports 2FA with the new U2F protocol. With this protocol the app id (uri) is part of the process and its provided by the browser. Thus phishing attacks will fail.

Sadly Firefox and other broswers do not yet support this, only Chrome. I really hope this replaces the old 2FA TOTP style and specially SMS.

For people who want to use both, there is a nice solution. You can use YubiKey as your U2F token and for websites that don't support this you can use the YubiKey as your 2FA with the help of a android app called 'Yubico Authenticater' and NFC. I prefer it to Google Authenticator because I can move between android devices (just came in useful when my phone broke).

Google does not yet support NFC U2F on their mobile browsers as far as I know. Thats very sad, I really want to be able to disable HOTP solution.

See the protocol here: https://image.slidesharecdn.com/fidou2fin10minutescis2015-15...


The article says, in "One Quick Check to Spot the Fakes!", to look for https instead of http. But this is no good: an attacker could use a domain-validated SSL certificate for the fake domains used.


This. The only way to check is to verify the certificate, which on Chrome means clicking the padlock, switching to the Connection tab, and then viewing certificate information. Not exactly straight forward.


The only way to check is to verify the certificate,

Or use a U2F key as a second factor. Avoiding MITM fishing attacks is one its explicit design goals. In short: the MITM does not have the right key handle, so it cannot initiate the challenge-response.

https://developers.yubico.com/U2F/Protocol_details/Overview.... https://developers.yubico.com/U2F/Protocol_details/Key_gener... https://developers.yubico.com/U2F/Protocol_details/fido-u2f-...

U2F is supported by Google and Dropbox (since one or two weeks). Keys cost ~10-15 Euro a pop. Buy two keys, keep one with you, put the other in a fire-proof safe.


If you already trust your CA authorities and you already know what domain to expect, then that's not necessary, you only need to check for HTTPS and the domain name.


Checking the domain name isn't sufficient because some letters look similar to each other and not all users are capable of doing precise string comparison matching in the same way that programmers do. The article has an example - qoogle.com instead of google.com. I bet that a significant number of users would miss this when asked to check.


How does it differ from checking the domain name in the certificate? I don't get it.


It doesn't differ from checking the domain name in the certificate. It does differ from checking the entity in the EV certificate, which is generally the legal name of the company.

In theory, a phisher could register a company with a similar name to the target website's legal name, obtain a valid EV certificate for that, and then phish using a similar looking domain with a similar looking EV certificate legal name. In practice, if that were to begin happening, I'd like to think that the authorities in charge of legal entity registration (eg. Companies House in the UK) would start requiring identity checks for the legal entity registrations, and then phishers would not have an easy path to exploit this route.


The discussion started with only mentioning DV certificates.

> I'd like to think that the authorities in charge of legal entity registration (eg. Companies House in the UK) would start requiring identity checks for the legal entity registrations

Wait, they don't require that now?


The only real protection from this is to verify that the SSL icon is displayed in the address bar, and that the domain is the domain you expected. It's a shame more websites don't educate users to do this.

This gives me an idea for a Javascript widget that guides users to verify the address bar, with an appropriate demonstration screenshot based on the expected domain, and the user's browser.


Worse, websites will redirect you to a different domain as part of their normal process.

For example, in the UK, the Lloyds Bank main website is lloydsbank.com, but click (on their insecure page) for online banking logon and you're taken to https://online.lloydsbank.co.uk.

The main website for another UK bank, NatWest, is on natwest.com (it redirects to http://personal.natwest.com), but click for online banking and you're taken to a page on https://www.nwolb.com

Telling users to check the domain is useless, since legitimate sites condition users to ignore it.

EV certificates do fix this to some extent, but users are not conditioned to check these, and it domain-validated certificates just complicate matters for them.

I would prefer to see legislation that mandates security standards for entities that handle personal data. In the UK, secondary legislation against an amended Data Protection Act that mandates EV certificates would work well for this, IMHO. This won't help the Internet at large, but would at least help condition UK users to know what to check.


I'd love to see EV certificates everywhere, and cheap enough that made them practical for small business owners who collect minimal personal information. Should you really need an EV certificate to have a newsletter sign up form? Probably not, but I wouldn't mind if it weren't for the fact that I'd pay over 200 pounds a year [0] for the privilege.

But absolutely, anyone storing serious personal information (credit cards, banking information, social security numbers) should be required by law to have an EV cert.

[0] https://www.geotrust.com/uk/ssl/


> I wouldn't mind if it weren't for the fact that I'd pay over 200 pounds a year for the privilege.

CertSimple is run from London, 150 quid a year, and delivers EV certs faster than anywhere in the world - an average of 5 hours, rather than the industry standard 7 to 10 days'. it also has an 80 second request process without software installation or terminal Q and A:

https://certsimple.com


My issue with that is the users no longer know what to check - having two types of certificates is confusing.

I'd be happy if you used domain-validated SSL but browsers didn't make any claims about the security of connections without the EV cert though. For me this means no padlock icon whatsoever. After all - from the perspective of an ordinary user who cannot verify your domain, it is insecure.

Edit: how about "No claims about security to be presented to the user without EV certificates"?


Microsoft Edge shows a hollow grey lock for DV certs: https://certsimple.com/blog/dv-ssl-in-microsoft-edge


The connection to a website with a DV certificate is certainly secure, it just isn't authenticated. TLS is designed to provide both, and EV follows through on that second promise.


This is a question of semantics - one that everyday users don't care about. To them, unauthenticated is insecure.


I guess it was impossible to have a secure session before the introduction of EV in 2007 then. I guess all these https sites (this one included) have been fooling me all along, with their fake secure connections.


Well yeah, you could register a domain validated cert for hotmaillogin.com, or for ..company.com (and then register hotmail.com.company.com) at the time just fine, and plenty of people did.


To me, encryption without proof of identity isn't secure. But as the other poster notes, this is semantics.


Is their some kind of addon that warns people about url that look the simular? That might be easy and useful.

Edit: With certificate pinning you could put out a msg to the User to verfiy if he understands that this is the first time he visits the site.

The problem is when to put out such a warning, i dont want to do that every time I go on a new site.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: