171–180 of 225 posts
Earlier quoted context omitted.
This frustrates me endlessly about Namecheap. They only allow SMS, and, for something as valuable as my domain name (figuratively the keys to my kingdom), that's unacceptable.
Have you tried using a (free) Google Voice number for 2FA purposes? Google Voice has no/minimal customer support, so it should be almost as secure as your Google Account.
Earlier quoted context omitted.
SMS as a 2nd factor represents an engineering trade-off. Prior to its introduction, the only people who had access to 2FA were people who got $60 tokens from RSA. It blocks against certain classes of attacks, but is vulnerable to others (like malicious or insecure carriers). Now, Apple users can use their fingerprint as a 2nd factor (e.g. for Apple Pay), but fingerprints have the unfortunate property of not being rot…
You can get a pre printed card for cheap for 2fa. No need for RSA token
The problem with SS7 is that trust is assumed. Mobile carriers that have roaming agreements will have either a direct link or via a hub. So what happened here was the network of the foreign roaming partner was used to redirect the SMS traffic on the victims carriers. Would not be surprised if it was an inside job. With ss7 you can do fun things like query the last location update/logged in base station for a mobile p…
The roaming hole was known to Russian blackhat scene, and was actively exploited for ages. I say, first number hijacking services were offered around 2001 to 2005, when Russia had a paid SMS content craze. Back then, the most apparent use of that was to steal somebody's number and then send paid sms to your number.
The fact that big IMEI databases gathered with Android scamware are now being sold around "social marketing" community only makes things worse.
The best known attack with that was an attempted hacking of British MPs personal emails a few years ago. Russian phone operator Megafon was complicit, yet they never even got a slap on the wrist.
All and every eMail or blog site that has password reset through SMS (Including whats up, and gmail) is open to that attack.
Earlier quoted context omitted.
Note that one time codes do not protect against phishing the same way U2F does (U2F is always bound to secure origin).
U2F is great but everything is better than SMS.
"If you want to transfer $1000 to account 1243567890, confirm with code ABCDEF".
Assuming an attentive user, this protects against malware silently changing amount and recipient on a transaction the user is making - an attack the banks were struggling with. It also makes phishing much harder, since the attacker needs to convince the user to enter the code after reading this message.
Code-based 2FA is vulnerable to phishing where the attacker relays the phished credentials in real time. German banks were doing 2FA long ago, in the form of sheets of paper with one-time passwords (called TAN). Attackers were phishing those, so banks switched to "indexed" (iTAN) OTPs: The bank tells you which OTP to use, so someone who has just phished 1 or 2 won't be able to use theirs. Phishers started relaying the stolen credentials to the bank in real time, looking which iTAN the bank asks for, then asking the victim for the same.
Given these known capabilities of attackers, any 2FA method that is not phishing resistant and not bound to a specific transaction is not usable, and probably not better than SMS. Anyone can make a phishing site, running attacks on phone networks is harder.
Edit: Just realized that U2F would not be a suitable solution for banks, since it does not authenticate specific transactions, so malware could still swap recipient and amount.
My bank's 2FA literally comes on a piece of paper. A set of numbered codes, and the banking app/site tells me which code to use for any given transfer.
Yea, I have the same from two different banks. For me this seems to be the obvious 2FA solution, but comments here are mostly about elaborate technical approaches. Is there something I'm missing?
Earlier quoted context omitted.
SMS as a 2nd factor represents an engineering trade-off. Prior to its introduction, the only people who had access to 2FA were people who got $60 tokens from RSA. It blocks against certain classes of attacks, but is vulnerable to others (like malicious or insecure carriers). Now, Apple users can use their fingerprint as a 2nd factor (e.g. for Apple Pay), but fingerprints have the unfortunate property of not being rot…
The big problem that SMS solves that nothing else does is that you can be completely irresponsible/unlucky and it still works. You can lose your u2f key , lose any one time backup codes on paper, and so long as you can convince your phone company that you are you you're fine. I don't think most people are responsible enough to deal with more secure MFA. Most people don't know how to keep custody of stuff like that.
Banks here in the UK use your chip & pin based card as a second factor (or rather, as the two factors - the chip you have, the pin you know) - they give you a little card reader that can use the card and pin to provide a 2FA token for logging in or sign requests to send money. It's a much better system. Of course, some banks don't use it to it's full potential - many use it only for signing money transfers, but it's…
Edit: I also don't need to make transactions often enough for it to be cumbersome - if I was travelling a lot for business and needed to make a lot of transactions, I'd worry about losing the device and being unable to do anything without it.
Banks here in the UK use your chip & pin based card as a second factor (or rather, as the two factors - the chip you have, the pin you know) - they give you a little card reader that can use the card and pin to provide a 2FA token for logging in or sign requests to send money. It's a much better system. Of course, some banks don't use it to it's full potential - many use it only for signing money transfers, but it's…
I have always been curious, do those devices work on linux?
They also seem to be trying in general to move everybody off the USB reader and smart card solution to a smartphone app based solution, so that the total number of people using the USB reader approach is down substantially.
Earlier quoted context omitted.
In the US they have finally started rolling out chip-based cards. However, there's no PIN needed if you run the card as credit, defeating much of the security.
>defeating much of the security. In many ways, this is better, since a skimmer can't grab my pin and credit cards have rules where they must immediately refund fraudulent purchases, while debit cards are often much more difficult to reverse.
Earlier quoted context omitted.
U2F is great but everything is better than SMS.
SMS can provide transaction authentication: "If you want to transfer $1000 to account 1243567890, confirm with code ABCDEF". Assuming an attentive user, this protects against malware silently changing amount and recipient on a transaction the user is making - an attack the banks were struggling with. It also makes phishing much harder, since the attacker needs to convince the user to enter the code after reading this…
U2F was designed to protect login where you don't need more context except the site you're logging into and that's protected as part of the protocol. Abusing it for other purposes (tx confirmation) as you showed is not a good idea.
Transaction confirmation can be improved by using mobile banking app that displays the transaction info and has accept / reject buttons. The communication would go over HTTPS.
But the problem of trust goes deeper - how do you know that account X is the correct number for your intended recipient? You usually have this saved in you banking system and when it is compromised you'd still be convicted that you're sending money to correct account. Unless of course you have a paper backup of account numbers...