[HN Gopher] That's not how 2FA works
___________________________________________________________________
That's not how 2FA works
Author : edent
Score : 231 points
Date : 2021-01-17 12:45 UTC (10 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| sneak wrote:
| You don't need a $50 Yubikey token to do U2F, there are ones in
| the $10-15 range.
|
| Most sites that support U2F support enrolling multiple tokens, so
| just have one in each machine.
|
| Theft of a machine still needs your password to access the
| accounts, so it's not "keys to the kingdom" as the article
| suggests.
|
| I feel that this article is... wrong.
| hehehaha wrote:
| Not sure why the author is so negative on Yubikey. His only
| reason is that an attacker can steal his laptop with the key
| plugged in. That's a user error.
|
| I much rather have Yubikey over all other forms of security
| because it simply forces the attacker to be physically present.
| Why is that important? Because even if your laptop is stolen with
| your Yubikey at a local Starbucks, you're more likely to catch
| that person versus a completely remote attack. Security isn't
| just about attacks. You also need to think about mitigation and
| recovery following the attack.
| zimbatm wrote:
| Another issue not mentioned by the author is what happens if
| the Yubikey is lost or breaks. The story around this type of
| event is sort of ignored and not understood properly. AFAIK
| it's not possible to duplicate a key (by design), meaning that
| the user will have to update all their websites' 2FA (hopefully
| there is a recovery method available).
| hehehaha wrote:
| Yes. You must have at least two keys registered. However it's
| worth noting that most services do not offer priority.
| Meaning you can use either one. I think it makes sense to
| designate back up keys and only to be used when user reports
| lost/stolen primary key.
| thatnerdyguy wrote:
| But what is the story there? You have a backup key,
| hopefully stored "off site", now you want to enroll in
| another website. You have to get that backup key before you
| do that? Or bookkeep which sites you have on the backup key
| and which you don't?
| taeric wrote:
| Actually, this is one area where pgp's use in pass works
| really well. You use your public key to encrypt
| passwords. So, adding a new one doesn't need the physical
| key.
| hehehaha wrote:
| This is a very good point and perhaps something Yubikey
| and similar services should consider: paired keys. Once
| paired the backup can always replace original if user
| reports it missing or lost regardless of when they were
| paired.
| PeterisP wrote:
| While it's not possible to duplicate an existing key, it is
| possible to create duplicate keys in the first place - you
| can't get the secrets out, but you can write identical
| secrets to two or more keys if you want to.
|
| This adds some convenience, though it also does add some
| risks e.g. in case of breach you can't tell which token was
| misused, you can't invalidate a lost key without invalidating
| others at the same time.
| signal11 wrote:
| Also, Bluetooth based keys exist that don't have to be plugged
| in.
| edent wrote:
| Author here. I did provide a few other reasons - mostly around
| usability of YubiKeys. Try observing a non-techie set one up
| and tell me if you think it is as easy as it could be.
|
| Realistically, you're probably not going to catch a mugger.
| Otherwise robberies like that wouldn't occur. Snatching a
| laptop with a key physically plugged in it is probably easier
| than snatching a laptop and a separate phone.
|
| Regardless of my opinions on tech, if you think being mugged is
| "user error" then may I suggest spending a couple of days
| volunteering for a local Victim Support charity.
| pg_bot wrote:
| Speaking as an author of a webauthn library who helps users
| set up their security keys as part of their training, it's
| about as easy as it can be. We give each of our customers 2
| yubikeys for each user when they sign up, tell them to keep
| one on their keychain and the other in a safe location only
| accessible to them. If you lose/destroy your main key revoke
| its access use your backup and buy/setup a new one. No one
| has had difficulty understanding the process for our site
| since we show them all the steps up front and describe what
| to do in common scenarios. If your customers have a problem
| setting it up, it's a reflection of poor user experience not
| protocol design.
| hehehaha wrote:
| Hey I understand but didn't think other reasons were valid. I
| apologize if my comment came out curt. I know how that feels.
| However, I think you should reconsider your opinions on
| Yubikey. They're significantly better than all other
| commercially available security solutions at the moment.
|
| Edit: your comment also gave me an idea. Perhaps there should
| be a phone-based service that you can dial that locks out
| your account for a predetermined time period? Or it could
| even be tied to someone else that you can trust.
| nwotnagrom wrote:
| I agree on the idea around usability of YubiKeys. I have them
| also and believe they are great, but I never seem to have
| them when I need them. Of course, maybe its on another floor
| or another room and I am being lazy not walking over there,
| but it is an added inconvenience on a process that needs to
| be balanced between security and convenience.
| proactivesvcs wrote:
| Adding a rotating 2FA to a password database, for one.
| ahmedalsudani wrote:
| _> may I suggest spending a couple of days volunteering for a
| local Victim Support charity._
|
| Please try being less condescending.
|
| Losing the keys, due to whatever reason, means losing one
| factor. If the user loses the key, the "mugger" still needs
| to get the users' passwords.
|
| 2FA = something you know + something you own. Having one
| factor compromised should not compromise your accounts if the
| service you are using is configured correctly.
| Closi wrote:
| What's the second factor with yubikey? The site seems to
| say it's passwordless.
| growse wrote:
| A yubikey doesn't replace a password.
| IncRnd wrote:
| > 2FA = something you know + something you own.
|
| That's not exactly correct. Another factor is something you
| are, such as a fingerprint or eye. There are three classes
| of factors from which drawing any two is called 2FA.
|
| There is also a 1.5 factor auth, used for example by many
| banks, in which there is a server challenge for the very
| vulnerability stated in the article.
| lrvick wrote:
| I have helped literally hundreds of people setup Yubikeys
| across several companies.
|
| Your take is just not my experience at all. Tapping a
| blinking light it is much easier than fussing with a 2FA app
| and works when someone's phone is dead. Yubikeys in
| particular are near indestructible. They even work after you
| soak them in acetone overnight and melt the plastic off. I
| tried.
|
| When it says "plug in your device" you plug it in. When it
| says tap you tap.
|
| Also the mugger comment is not part of a typical threat
| profile. Yubikeys and similar devices are meant to protect
| you from remote attackers which is the class of attack
| 99.9999% of people need to defend against.
|
| If a mugger points a gun at you, no form of 2FA is going to
| save you.
|
| Also my Yubikey has a pin enabled and fingerprint enabled
| WebAuthn devices exist. I have several. If you are carrying
| things so valuable you are worried about being mugged, you
| can probably afford a higher end model with a fingerprint or
| pin.
|
| Edit: yes I know random muggings happen, but a hit and run
| mugger that knows what a Yubikey is and already has your
| password is a hiiiiighly targeted attack. -That- pretty much
| never happens unless you are walking around with a $1,000,000
| in Bitcoin in which case it has happened a total of 5 times
| that are public.
| screamingninja wrote:
| > If a mugger points a gun at you, no form of 2FA is going
| to save you.
|
| https://xkcd.com/538/
| fjiizrsdfjjj wrote:
| If my Yubikey gets stolen, how do I log in into my
| accounts?
|
| Serious question; never understood how that works.
| mwarkentin wrote:
| This was confusing to me until I realized a couple of
| things:
|
| - you can still have TOTP enabled on the site as a backup
| 2FA method - you can configure multiple yubi keys for a
| single site - so I have one on my keychain that does NFC
| + USB-C for my MBP, and another "Nano" key that is left
| in my home imac - they are both registered with most of
| the sites I've configured
|
| If my keychain is lost/stolen then I can still login from
| home or with my TOTP code as a fallback.
| andrewnicolalde wrote:
| Second yubikey ;)
| corty wrote:
| Depends. Some have a bunch of magic numbers you can use
| as alternative "second factor", basically another
| password for the special purpose of bypassing a real 2nd
| factor. That's of course stupid and dangerous.
|
| Then there are those where you can register another 2nd
| factor, e.g. another Fido-Key, SMS-Codes or recovery
| email. Those might be better or might be worse, depending
| on the method and circumstances. E.g. SMS is vulnerable
| to all kinds of SIM-Cloning and redirection stuff, email
| is vulnerable to whatever your email might be vulnerable
| to.
|
| The only thing I would accept as really idiot-proof and
| secure is "go someplace, show a government-issued hard-
| to-fake ID" (like a passport, not your drivers
| license...) like banks do. But that only works with
| physically present businesses and accounts that are
| strictly tied to one person. And even there, "Joe Smith"
| might impersonate "Joe Smith"...
| taeric wrote:
| This is akin to asking how do you start your car if you
| lose your keys? Enter your house? You have backups or
| other recourse to get things rekeyed.
| scott00 wrote:
| Some other responders have given you the answer as it
| currently exists. They are all either inconvenient,
| weaken security, or both. For that reason, I would only
| suggest using a security key for a small number of
| critical services, where it's worth the extra effort to
| deal with the backup mechanisms.
|
| However, a good solution for this issue is finally in the
| works: https://www.yubico.com/blog/yubico-proposes-
| webauthn-protoco...
| cbsmith wrote:
| Having two keys, one of which you keep in a secure place,
| seems pretty simple and intuitive to me.
| scott00 wrote:
| What does your workflow look like when you set up new
| credentials?
| andrewnicolalde wrote:
| If you mean when registering for a new account,
| annoyingly you need to physically have each key with you
| to register it with a new service. Biggest flaw in the
| spec IMO.
| proactivesvcs wrote:
| The last time I've used the configurators on Windows and
| Linux they provide the private key material for one to
| backup.
| wyager wrote:
| I have a backup U2F device. You can register multiple
| with any account.
|
| If I somehow manage to lose both, I assume I'll have to
| talk to a customer support rep or something.
| growse wrote:
| This depends on the service supporting it though, and not
| all of them do (e.g. AWS).
| ahmedalsudani wrote:
| That's how 2FA works. It's a physical token.
|
| You either have other 2FA devices or backup codes.
| ajcp wrote:
| If it's so easy why did you have to help hundreds of people
| across several companies set it up?
| tialaramex wrote:
| You have to (well, I guess if it isn't your job you don't
| _have_ to but it 's polite) help people set up anything.
| Doesn't mean it isn't easy. Helped my mum set up Zoom (so
| she could attend virtual church apparently), is Zoom not
| easy?
|
| Two (three?) jobs back I had to set a bunch of people up
| on one time passcodes. Those seem pretty easy right?
| Still had to go there in person and show them.
| cbsmith wrote:
| Being mugged isn't "user error", and the good part about
| YubiKeys is that the consequences of being mugged are much
| more intuitive (it's just like I had my keys stolen).
|
| The "I left my keys in my coat" problem you have seems like
| it has a pretty obvious solution: don't keep your YubiKey on
| your key chain. Do you have a wallet or cell phone that you
| carry with you at all times? Put it in the wallet or cell
| phone case.
| gnufx wrote:
| I've spent a lot of my life around Toxteth and Moss Side, and
| that doesn't affect my threat model relevant to phishing and
| FIDO. Mugging is probably less of a threat than break-in
| anyway, as far as compromised hardware goes. You separate the
| token when it's at risk, and the setup procedure claimed for
| FIDO, to the extent it exists, seems about as easy as it
| could be. It's a key. People can understand physical security
| to a reasonable degree, and typically not abstract computer
| security.
| drivebycomment wrote:
| Your opinion is in this case based on your ignorance and
| misunderstandings. The main threat model U2F key protects
| against is phishing, and phishing is the largest threat
| currently. The password is sufficient to protect you for
| opportunistic offline attacks like theft or loss.
| Ottolay wrote:
| Fully agree that a physical attack is much less likely.
|
| Also, the use of a PIN or fingerprint[1] to authenticate the
| yubikey itself and not sent over the network, mitigates the
| stolen key scenario. [2]
|
| [1] https://www.yubico.com/blog/getting-a-biometric-security-
| key... [2]
| https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
| 2Gkashmiri wrote:
| https://www.amazon.in/Auto-ePass-2003-FIPS-Token/dp/B00S7LUL...
|
| does anyone know if its posible to reuse these fips pki tokens?
| they are cheap enough.....
| vaduz wrote:
| It's essentially a smartcard (certificate storage) in a more
| convenient form factor for most users, so you could use them to
| store your RSA keys - though personally I would not trust them
| - but they are not FIDO/FIDO2 so they are almost useless in the
| context of the article.
| tommywg7 wrote:
| What about certificates? The fake GitHub almost certainly does
| not have a valid certificate. Isn't that our one defense against
| these things?
| tialaramex wrote:
| The problem that a certificate just assures us this is indeed
| https://githubverification.com/ which it is
|
| This leaves a _human_ to try to make deductions about whether
| githubverification.com is github.com which is something humans
| are terrible at, so game over.
|
| If you have WebAuthn then your browser also takes
| responsibility for only letting you use your github.com
| credentials on github.com and not even bothering you with any
| other possibilities that you might think could be safe and are
| not. That's why WebAuthn prevents phishing.
| latopedej wrote:
| fido2/webauthn, adds MFA and a anti phishing protection!
| latopedej wrote:
| more convenient than yubikeys, is simply your phone, which is
| really often near you
| md_ wrote:
| Mostly agree with a lot of this, but it's a little unfortunate to
| lump all WebAuthn authenticators together.
|
| WebAuthn keys--physical dongles you plug into the USB port--are
| indeed problematic for the reasons the author notes. (A small--
| but user-visible--cost; the requirement for a spare USB port of
| the right form factor; loss.)
|
| However, authenticators that are built into the client device
| (e.g. Apple's support for a TouchID-verified WebAuthn
| authenticator) solve these problems, to varying degrees: the user
| doesn't see a marginal cost (it's built into the computer!) and
| doesn't have to worry about loss, USB ports, etc.
|
| The principle challenge with using (as an example) Safari's
| WebAuthn support is what how the relying party should support
| loss of the device. (If you lose your Safari--or claim to--how
| does your bank authenticate you?)
|
| Ultimately, the lost-device--or new-device bootstrapping--problem
| is currently what stands in the way of a truly secure ecosystem,
| but with platform providers increasingly supporting WebAuthn, we
| can at least _reduce_ phishing risk to "phishing of the platform
| provider credential." Your iCloud password might get stolen, but
| at least that's the _only_ thing an attacker can steal to gain
| access to your other accounts.
|
| For most services, delegating authentication (and anti-phishing)
| to someone like Apple is a big plus.
| drcongo wrote:
| I use Krypton [0] as a virtual YubiKey, I like it a lot but
| they got acquired by Akamai and the GitHub accounts have gone
| worryingly quiet.
|
| [0] https://krypt.co
| md_ wrote:
| That's cool. Either I haven't seen this before or I've
| forgotten. :)
|
| I do think (as I said elsewhere here) that ultimately people
| will adopt WebAuthn via their browser/OS vendor. Support is
| widespread! But for relying parties, there are still
| challenges to solve.
| dane-pgp wrote:
| > Krypton is built on top of an end-to-end verified and
| encrypted architecture. This means zero trust. We, Krypt.co,
| cannot access your keys or see where you're authenticating.
| The keys only live in the Krypton app on your phone.
|
| Sounds great, except one of the "ends" is likely the Secure
| Enclave (iOS) or Keystore (Android), over which the user has
| basically no control. So while the architecture might require
| "zero trust" of Krypt.co, it still requires complete trust of
| Apple or Google.
|
| Perhaps completely trusting one of those companies is already
| the reality for nearly everyone, in terms of using a mobile
| device to access online data, but hopefully WebAuthn-
| supporting sites don't put extra restrictions on the devices
| you can use, via the "feature" of attestation:
|
| https://www.imperialviolet.org/2019/01/01/zkattestation.html
| judge2020 wrote:
| Trusting your HSM vendor is a requirement if you don't want
| your keys to be exportable, and there's much less risk in
| doing so compared to trusting Apple for other things like
| secure communications (iMessage is e2ee but doesn't tell
| you when your peer changes/adds keys, plus unencrypted
| backups are on by default).
|
| Also, a lot of people who use Krypton don't know that SSH
| keys actually don't use the secure enclave because it
| doesn't support rsa or ed25519:
| https://github.com/kryptco/krypton-
| ios/issues/73#issuecommen...
| edent wrote:
| I think that's a fair comment. It would be great to see more
| device come with built in support for this.
| md_ wrote:
| Platform support isn't exactly the problem.
|
| Apple, Microsoft, and Android all support WebAuth
| (https://blog.mozilla.org/security/2019/03/19/passwordless-
| we..., https://webkit.org/blog/11312/meet-face-id-and-touch-
| id-for-..., https://docs.microsoft.com/en-
| us/windows/security/identity-p..., https://developers.google.
| com/identity/fido/android/native-a...), so most (??) users
| are in fact covered.
|
| eBay, for example, offers a passwordless experience using
| WebAuthn--so it can be done, even on a major consumer site.
|
| The problem is really that until relying parties can trust
| that
|
| 1. Platforms will backup and restore key material from
| authenticators 2. Users will figure out how to use those
| backups (including if they e.g. switch from Mac to Windows)
|
| they will have to provide some fallback. (Realistically, that
| means "for the foreseeable future.")
|
| This relegates WebAuthn, unfortunately, to a "neat trick"--
| eBay's "passwordless option"--and not a security guarantee.
| (Phishers can always downgrade the user to passwords or
| similar.)
|
| What's needed in the interregnum is probably a way to make
| that fallback option more secure by, at minimum, conveying to
| users that it's not _normal_--so that phishing attempts
| targeting that phishable backup are less likely to succeed.
|
| Unfortunately this requires a lot of good UX design and
| unilateral action on part of the relying parties, which I
| think is tough.
| 3np wrote:
| I also think the most of the issues they bring up I understand
| as adoption (which gets improved by increased adoption on the
| user side), tolling maturity, and habits.
|
| TOTP and U2F actually has achieved pretty wide adoption, so I
| have hopes for WebAuthn.
| sigmar wrote:
| > Buy a device, register it, install the app,
|
| What u2f app is this referring to? I've never needed anything
| more than chrome to use u2f on windows or ubuntu. Also seems
| weird to complain about setting up an app, when a few sentences
| before that they recommend installing a password manager...
| edent wrote:
| YubiKey recommended that I install Yubi Auth
| https://play.google.com/store/apps/details?id=com.yubico.yub...
| and YubiClip
| https://play.google.com/store/apps/details?id=com.yubico.yub...
|
| Should I not have?
| tytso wrote:
| If you had used one of the $10 USD Webauthn (aka U2F) tokens,
| it wouldn't have asked you to install any applications.
|
| The "problem" is the expensive Yubikeys that you were whining
| about has lots of extra functionality that has nothing to do
| with U2F, and that's what the extra applications are all
| about.
|
| I happen to use a Yubikey because I _want_ that extra
| functionality, including using it to secure the keys I use
| for ssh and for digitally signing git tags so I can securely
| push git pull requests. But that 's because I'm a developer,
| and it's why I'm happy to purchase multiple Yubikeys (one for
| my desktop, one for laptop, backups including one that is on
| a keychain, etc.) Perhaps you were reading web sites that was
| giving advice for developers as opposed to for consumers?
| wyager wrote:
| OpenSSH >= 8.something natively supports U2F. No need for
| extra functionality.
| tialaramex wrote:
| However, to use native FIDO the SSH _server_ must accept
| it (GitHub does not for example)
|
| Whereas if you have RSA keys on the "full fat" Yubikey,
| they can be used regardless.
| Ottolay wrote:
| For U2F specifically you don't need apps except support in
| the browser. The apps you listed are used for other types of
| functionality provided by the yubikey, like OTP and TOTP.
| nrvn wrote:
| I have a question: if a website is clearly involved in phishing
| how does one report such a website and what is the process of
| blocking the domain name and chasing the owner?
| ahmedalsudani wrote:
| _> Risk. YubiKeys have no password lock of their own. At least my
| crumby Android has a fingerprint lock to prevent people getting
| my 2FA tokens. But if you've stolen my laptop and the YubiKey is
| plugged in, then you've got the keys to my kingdom._
|
| The key is only the second factor. You need to lose the key *and*
| have your password stolen in order to have your accounts
| compromised. At that point, think about what you're doing wrong
| as a user.
| swinglock wrote:
| So almost nothing can be done because
|
| > The top result on Google is invariably an advert for a scam
| site.
|
| No, use an adblocker. It's the modern antivirus and you should
| use one.
| lrvick wrote:
| The Yubikey/WebAuthn comments are really ignorant and
| discouraging people from the best defense against this sort of
| attack that exists.
|
| First of all you can get WebAuthn devices for as little as $10
| now.
|
| Second, there is no app to configure. You plug it in when it says
| register and tap it. Done.
|
| Third, if the WebAuthn device gets stolen the attacker presumably
| lacks a password. You can't use the device by itself. Also the
| vast majority of attacks are remote, not IRL.
|
| Fourth: fingerprint or pin authenticated WebAuthn devices exist
| if your threat model worries about physical access.
|
| IRL attacks are a radically different threat profile.
|
| I can't even with this article.
| wyager wrote:
| Plus, iPhones already support webauthn via Face ID, and I
| assume MacBooks will support it via Touch ID at some point.
| justincormack wrote:
| It is disappointing that touch id doesn't support this yet,
| it would be great. I put my ssh keys on touch id but my
| webauthn and gpg are on the yubikey and I have to remember
| which to touch. And the yubikey with finger print reader isnt
| out yet and I already have pretty much the right hardware in
| the mac...
| easterncalculus wrote:
| Disappointed but not surprised when reading this. To be really
| honest, I can't remember the last time I read something that
| criticized so called "techbros" and actually said something
| reasonable.
|
| As for the U2F devices, the idea of just leaving them in, the
| small yubikeys and all that, seem to just be a bad idea from
| the get-go.
| goodpoint wrote:
| Found the techbro.
| Freak_NL wrote:
| You can leave them in, but you still have to tap/touch them
| for every authentication action (user interaction); the small
| YubiKey Nano included.
| wyager wrote:
| What is your objection to just leaving a yubikey plugged in?
| It eliminates most of the ways an attacker could impersonate
| me besides literally stealing my laptop, which is a high bar.
| Most people are valuable enough targets to phish or infect
| with malware or something, but not to plan a computer heist.
| kps wrote:
| If stealing the computer is enough, someone's seriously
| screwed up already -- it's supposed to be 2FA, not 1FA.
| aidenn0 wrote:
| Stealing the computer is usually enough, as a browser
| cookie serves as proof of authentication all on its own.
| Some destructive operations require extra auth, but in
| terms of data exfiltration, stealing a laptop gives you
| everything you need.
| izacus wrote:
| What exactly does that have to do with YubiKeys though?
| Every time you use one you need to enter password. And
| you can also immediately revoke it as soon as you notice
| its stolen.
| aidenn0 wrote:
| I kind of omitted that part. Having a YubiKey in or not
| in the laptop won't really affect things (other than the
| fact that you will need to get into your account somehow
| without the yubikey if the yubikey is stolen).
| latopedej wrote:
| most people have a phone that can leverage webauthn, so you
| don't even need to buy anything. On top of that, webauthn can
| be configured to prevent phishing as well
| edent wrote:
| Could you let me know where I can buy a well supported WebAuthn
| key for that price?
|
| Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest
| appears to be about PS30. Unless I want to risk my security to
| some no-name brand with zero customer support.
|
| When I got my YubiKey, it told me I had to download an Android
| app to make it work. So, perhaps better documentation is
| needed?
|
| I'm sorry you didn't like my post, I'll try to do better in
| future.
| _wldu wrote:
| Conor sold U2F Zero's for less than 10 dollars (years ago)
| and has a kick starter now to fund his new Solo keys:
|
| https://www.kickstarter.com/projects/conorpatrick/solo-
| the-f...
|
| https://u2fzero.com/
|
| I have a few U2F Zeros and they have been working fine for
| years. These are simple devices. You don't need to overpay
| for them.
|
| Edit: Conor was building the U2F Zero tokens for $2.26 USD
| per unit. Read more here:
|
| https://www.conorpp.com/u2f-zero-year-in-review/
| gnufx wrote:
| I don't think the kickstarter is relevant now. You just buy
| them from solokeys.com. There's been Somu since that, and
| Solo2 is in the offing, with plenty of storage, apparently.
| I bought Somu partly for convenience, and partly for the
| promise of PGP support, which unfortunately hasn't been
| added yet (though there is a development version).
|
| In answer to the expense question, two Solo keys appear to
| set you back 38 quid at the current exchange rate. I don't
| know how they compare with HYPERFIDO, which I don't think
| I'd come across before.
| bsder wrote:
| > I bought Somu partly for convenience, and partly for
| the promise of PGP support, which unfortunately hasn't
| been added yet (though there is a development version).
|
| It is sad that with PGP being so horribly broken, it
| still casts its shadow over security products.
|
| PGP should have been dead and buried eons ago.
| ecesena wrote:
| I can confirm what you and _wldu are saying and yes, the
| latest project is https://solokeys.com/v2 and is
| launching end of this month.
|
| From an economic perspective, unfortunately, it's really
| hard to focus on reducing the cost, there's simply no
| incentive.
|
| First, consider that the biggest cost in the customer
| getting a security key is basically shipping + packaging.
| Imagine a key that costs <$3... even packaging with a
| polybag + printed label + padded envelop gets to a cost
| that has a significant % of the production cost.
|
| Next, it's features. To stay on par with competition,
| people expect the same features (see, e.g., openpgp
| mentioned above - the code currently doesn't fit in the
| stm32l4 flash), both firmware and hardware. As a result
| we have to look at the latest & greatest micro, but of
| course that alone has a significant cost.
|
| And finally, there's the overall viability. We all know
| that open source projects die without a business model.
| The numbers in the U2FZero review simply don't add up,
| that was clearly unsustainable and that's why we made
| SoloKeys. A business has expenses other than
| manufacturing and if you don't account for that, the
| business dies together with your dream project.
|
| Anyway, thank you both (and all others) for the great
| support. One step at a time, we'll get to a stronger and
| eventually also cheaper product!
| gnufx wrote:
| Ah, I didn't know about the PGP code size. Point taken
| about the cost, and I hope you can sell to organizations.
| I'm surprised I can buy a competitor for PS8, but then I
| can't run the proprietary programming software or, I
| assume, re-flash it. I'm happy to support a free software
| project anyhow. I wish I could register my Somu with the
| work Duo system rather than the display-a-number-you-type
| HOTP keys they reluctantly issue as the expensive
| alternative to expecting us to use personal phones for
| such purposes. Phishing, we've heard of it.
| captn3m0 wrote:
| The HYPERFIDO Mini keys (8 GBP[0,1]) are certified by the
| FIDO Alliance: https://fidoalliance.org/showcase/hyperfido-
| mini/.
|
| [0]: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-
| Security/...
|
| [1]: https://www.hypersecu.com/products/hyperfido
| avipars wrote:
| AMAZON AFFILIATE LINK. Please delete....
| tialaramex wrote:
| The HyperFIDO is basically fine, it's obviously your choice
| to insist on the expensive famous brand products, but it
| seems a bit crazy to on the one hand insist those are too
| expensive and then reject perfectly good cheap options.
|
| If I had a corporate budget to spend maybe I'd order trays of
| Yubico Security Keys or Google's Feitian rebrand. But I just
| wanted to have more than one vendor so I have this product
| (well not this one, but it's the same product under different
| branding) and it works fine.
| DecoPerson wrote:
| For the reasons listed in the article and more, Yubikeys and
| similar devices aren't likely to ever be popular.
|
| To give future security devices along the same vain a better
| chance at gaining popularity and being widely adopted (which
| will hopefully bringing us a more stable, less stressful
| society), the designs of these new devices must solve or
| workaround the issues the author describes.
|
| It's really annoying when individuals such as yourself respond
| so very negatively and unconstructively while others are trying
| to discuss the issues with existing designs -- an act necessary
| for us (collectively) to develop new designs.
|
| The author may not provide strong evidence for their claims,
| but neither do you provide strong evidence (or extensive
| reasoning) for yours. The net gain here is negligible, expect
| for showing that contrary opinions exist, but that's not
| particularly helpful as for every opinion held it is inevitable
| that someone holds the polar opposite.
|
| I'm not a moderator, but I ask you to please try to better
| further the discussion with future comments.
| hehehaha wrote:
| I think Yubikey (and similar physical solutions) will
| eventually gain popularity. Carrying a key is pretty much a
| standard practice across the globe and benefit is more than
| negligible because it forces physical attack versus
| remote/virtual.
| RajBhai wrote:
| I've long thought that U2F should be incorporated into
| phones, since everyone has one of those. Even not well off
| people in third world countries. In order for U2F to
| proliferate, everyone should have access to it. A $10 FIDO
| key probably won't be given a consideration if they think a
| free password is good enough.
| tialaramex wrote:
| WebAuthn is the modern replacement for U2F. Do not deploy
| greenfield U2F, it's a legacy technology only.
|
| A modern iPhone or high-end Android phone already does
| WebAuthn secured with your fingerprint or (on some iPhone
| models) facial recognition, like your lock screen or
| contactless payments.
| MrStonedOne wrote:
| Until keys become cloneable they will never gain
| popularity.
|
| Nobody wants to re-setup every site ever because they lost
| their laptop that they kept it plugged into, so they won't.
| either this means using their backup until they lose it
| without even revoking the original and then swearing off
| the entire concept while telling all their friends to do
| the same, or just not using hardware tokens after the first
| lost of keys.
|
| Also the "back up code" they will also get, guess where
| thats going! save as -> downloads or print2pdf ->
| downloads.
|
| When it comes to personal account security by end users,
| hardware tokens will never take off, and this is why they
| get so much hate.
|
| There is a real problem here that really needs to be really
| solved, wrt to end users and phishing/hack resistant
| credentials, and as long as we legitimize the lie that
| yubikey solves it, we gimp progress towards actually
| solving it.
| rstuart4133 wrote:
| I don't think cloneable is a good idea. If some 3rd party
| clones your token and uses it to commit a crime there is
| no way to prove that happened.
|
| There are other solutions. Being able to make one key a
| proxy for another is one. That allows you to keep your
| master identity in a bank vault, and then use it to
| "sign" the one you keep on you during the day. Should you
| lose your daily driver, just sign another one. This still
| suffers from the "one true name" problem though - if
| someone steals that bank vault ID, you're gone.
|
| Another approach is servers allowing a client to register
| multiple ID's, and later delete them. Since there are
| multiple ID's, there isn't one true name any more. If one
| is lost you cancel it, and replace it with another. The
| approach is already built into the FIDO2 protocol, so
| they've already thought about your concerns and solved
| them, and IMHO solved them in a better way than you
| propose.
|
| A more robust approach still would be a combination of
| the idea above: FIDO2 multiple ID's solution, plus
| proxies. One key could then provide multiple ID's to
| every server you log into, signed by different masters
| that are stored in different places. Keys can't be
| copied, but a lost key can be replaced by signing it with
| the master. A compromised master can be have all it's
| ID's dropped by logging in with an ID proxying other
| master. You could think of it as RAID for 2FA's.
| hehehaha wrote:
| I am not understanding your concern. You definitely don't
| want the keys to be "cloneable". You need at least two
| keys, sure, but I don't see that as an inconvenience. And
| you should be using a password manager (with passwords
| cycled on a periodic basis) that is bound to your
| physical key.
| cxr wrote:
| Instead of a hardware authenticator to be carried on a
| keyring, they should be put into rings, i.e., the things
| meant to be worn on your fingers, i.e., the things that
| most people use for providing input to their computing
| devices, whether they sit on a desk or are held in one's
| hands.
| hehehaha wrote:
| This is actually brilliant.
| tilsammans wrote:
| I had one twenty years ago, a Java Ring. Apparently they
| are still being made today.
| nightski wrote:
| I use a Yubikey daily and the OP is greatly exaggerating the
| issues in my opinion. Vanguard for example it took less than
| a minute to set up. I don't have an "application" installed
| locally for the Yubikey, it was plug & play. No special
| software needed.
|
| I honestly think Yubikey type devices' largest problems are -
| 1. Marketing. People simply do not know they exist or how
| they work (simple or not). 2. Support - Many websites do not
| support Webauthn yet. We really need developers and
| businesses to consider this a priority.
|
| I have bought some keys for my family members and they love
| them once I demonstrate how they work.
| guenthert wrote:
| Price. Yubikey's "best seller" goes for $45, that's
| grotesque. I would be surprised if the hardware costs
| exceeds $2 per unit and the software (or similar) can be
| had for free.
| bsder wrote:
| It's not about the hardware. In spite of the fact that
| they can nominally be broken into, most modern USB
| microcontrollers can easily implement being a security
| key.
|
| The expense is that the security world hasn't converged
| on anything remotely approaching a single standard. So, a
| key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
|
| For example, you couldn't use some of the older YubiKeys
| with AWS because AWS only supported time-based TOTP.
|
| That's a _LOT_ of software work, and you can 't be
| "Startup Sloppy" with your code or someone will break it.
| ak217 wrote:
| > I'm not a moderator, but I ask you to please try to better
| further the discussion with future comments.
|
| Please don't go there. You're both adding to the discussion,
| maybe some strong words here and there, but this turn of
| phrase you used is a huge conversation destroyer.
| m4tthumphrey wrote:
| Slightly OT: Odd timing but one of my services sent me a push
| notification earlier about setting up a "personalised code" which
| would be included in all emails. I thought this to be a novel way
| that could _help_ with the email phishing problem, if adopted and
| implemented properly.
| unilynx wrote:
| The user still has to notice that the personal code is missing
| in the phishing emails.
|
| If you could trust users with "always check for this personal
| code in the emails, ignore emails without it" we could also
| trust them with "your bank will never email you a login link"
| scottmcdot wrote:
| Is there potential for a simple popup in, say, 1Passwordx Chrome
| extension that, if the base url doesn't exist in any key chains,
| that reminds us to watch for phishing sites?
| Tomte wrote:
| > A second factor allows a site to better authenticate you. It
| does not help you identify the site.
|
| That's correct. On the first visit (or enrolment).
|
| All subsequent visits (many more!) do identify the site, or
| rather they tell you that you're logging in to the same site as
| all those times before.
| lkbm wrote:
| With an email link or a Yubikey it might, but with SMS or an
| Authenticator app it doesn't add any extra way for me to
| identify the site.
| gregoriol wrote:
| Email is not really a 2FA though if it can also be used to
| reset your password.
| lkbm wrote:
| Interesting point. I hadn't thought about that. Helps that
| access to my email is 2FA, but it does make for a single
| point of failure.
| Tomte wrote:
| That's true, I was talking about a Yubikey.
| louis-lau wrote:
| But the tweets this article was written in response to,
| weren't.
| jrochkind1 wrote:
| > All subsequent visits (many more!) do identify the site, or
| rather they tell you that you're logging in to the same site as
| all those times before.
|
| I don't understand what you mean. Something about 2FA does
| this? How?
| brazzy wrote:
| The U2F protocol (that Yubikey and others use) is based on a
| cryptographic challenge-response mechanisms, and it includes
| the domain of the service you're logging into, as supplied by
| the browser.
|
| The details are complicated, but basically: If you register
| the key at github.com and later get phished to visit
| githubverification.com, then the authentication will fail no
| matter what the phisher does.
| tialaramex wrote:
| Specifically, the phisherman's options for a typical
| Security Key (a physical authenticator device you buy and
| maybe plug into a USB port) are:
|
| * Spew random crap claiming it is your
| githubverification.com key ID, ask you to sign in with this
| ID. Your authenticator won't recognise this ID and it
| doesn't work
|
| * Proxy your real ID from github.com and present that from
| githubverification.com asking you to sign in. Your
| authenticator won't recognise this ID because it's for the
| wrong site, though it doesn't know that's why. It doesn't
| work.
|
| * Proxy the ID from github.com and insist _this_ is
| github.com. Your browser says "Er, no? This isn't
| github.com fool" and the UX doesn't fire.
|
| Notice that the attacker not only doesn't get working
| credentials for signing into GitHub, they don't even get
| broken failed credentials that don't work, they just get a
| Javascript error at best.
| ajross wrote:
| The linked article is correct, but uncharitable. It correctly
| states the behavior of two-factor auth systems but incorrectly
| understands their _value_.
|
| Yes, 2FA won't protect you from being phished by a site if you
| aren't careful. 2FA absolutely will protect you from a phishing
| site using the password it stole.
|
| So no, when someone says "Use 2FA if you might be phished" you
| shouldn't be replying "That's not how 2FA works", you should
| reply "That's right! But let me explain why you are still at risk
| of password theft and should still be careful."
| u801e wrote:
| > 2FA absolutely will protect you from a phishing site using
| the password it stole.
|
| That's assuming one used a different password for the email or
| mobile provider.
| [deleted]
| 8ytecoder wrote:
| If it's a website which supports API key or any token of sorts
| (without expiry or long expiry), they could do some real damage
| even if they can't use the 2FA again. Another thing would be to
| disable 2FA.
|
| All they have to do to achieve this is to use the phished
| credentials to immediately login with the original site,
| trigger 2FA and then show a field to capture it and pass along.
| Then capture all the cookies.
|
| The best defense against phishing is to use a password manager
| that does domain matching.
| cutemonster wrote:
| Any such password manager you like? Didn't know they could do
| domain matching
| dheera wrote:
| Also, I'm a big fan of U2F keys including Yubikeys.
|
| I don't use SMS, deprecated it 10 years ago in favor of e-mail,
| and would never use SMS for 2FA. I still have a virtual SMS
| number that forwards to my e-mail for the idiot sites that
| still insist on it.
|
| For most people, SMS is hackable, tied to a single battery-
| powered device, easy to steal (after which for most people in
| the default phone configuration the SMS verification codes will
| happily pop-up on the lock screen without unlocking the phone),
| and hugely inconvenient if you are in front of a desktop
| computer all day and have to go find your phone (at home for
| example I pretty much never have my phone next to me). SMS also
| famously locks people out of their accounts when they go to
| another country and have to use a different SIM card. Also, if
| you have a giant desktop in front of you, it's ridiculous to
| not use that as your 2FA device. You should NEVER have to pick
| up a 6" handheld device for 2FA when you have a massive
| immobile, hard-to-steal device in front of you that in my case
| is also physically locked down to furniture.
|
| Yubikeys and other U2F keys do exactly this.
|
| The article is wrong about one thing:
|
| "But if you've stolen my laptop and the YubiKey is plugged in,
| then you've got the keys to my kingdom."
|
| No. My preferred way to use Yubikeys is to buy one for each
| immobile device (home/office desktops) that stays plugged in,
| and ONE mobile key that lives in my wallet. Register all keys
| with critical services. If any device gets stolen (highly
| unlikely for the immobile devices, the mobile device is the
| only one I need to worry about really), go home, log in with
| another key and remotely disable it.
|
| My main gripe is websites that don't allow multiple Yubikeys.
| AWS is at the top of my hall of shame.
| jacksonkmarley wrote:
| > I still have a virtual SMS number that forwards to my
| e-mail for the idiot sites that still insist on it.
|
| Really? How? Last time I tried to do this it turned out that
| apps/sites would not send to these virtual SMS numbers.
| sulam wrote:
| I would love to be a fan of Yubikeys, in fact most people
| would say I _am_ a fan of Yubikeys, I think I have like 10 of
| them (due to product evolution and always buying a few when I
| buy one).
|
| Unfortunately most of the sites I use do not have anything to
| do with them.
| rdiddly wrote:
| _2FA absolutely will protect you from a phishing site using the
| password it stole._
|
| Not if it also steals the 2nd factor. My response would be more
| like "2FA is good but not for this problem." This problem is
| about going to the wrong site. The solution is to go only to
| the right site.
| smoyer wrote:
| I bought my whole family Yubikeys last Christmas for exactly
| this reason ... you can't trick someone into a hardware token
| authentication. Now I tell people to use something with U2F.
| I find myself using software U2F and include the secret key
| in my password manager so that I don't need a hardware key
| from my laptops.
| 8ytecoder wrote:
| How many websites allow U2F as the only 2FA? Every website
| I tied it wanted a backup authentication app added.
| dathinab wrote:
| Normally you can create backup hardware recovery keys (or
| alternate fallback 2F). (EDIT: Keys as in e.g.
| alphanumeric on time use tokens lie "23430240392")
|
| This is necessary as you would else wise be permanently
| be locked out if you lose your U2F key.
|
| That is assuming you can't reset your U2F key using mail
| password recovery. But your mail being a single point of
| failure is something U2F normally tries to prevent.
|
| Through I guess for not relevant services. I would still
| want U2F but allow mail recovery and maybe even U2F
| _only_ login (or FIDO login without PIN).
|
| Given that people have different opinions about what is
| important I guess this should be an option for fallback
| recovery, maybe with some warning around it.
|
| The "workaround" to have no fallback for U2F is to
| generate recovery keys and then not store them anywhere
| ;=). But I would not recommend this, except if they have
| a insecure mail based password/U2F recovery anyway.
| pc86 wrote:
| > _Not if it also steals the 2nd factor._
|
| Sure, but isn't that the point? There's now a second thing
| they have to steal, and if they only get the first it's
| pretty worthless, especially if there's monitoring/alerting
| in place that prompts a password change and/or locks your
| accounts pre-emptively.
| ascar wrote:
| As phishing usually includes impersonating a website and
| making the victim believe they are giving their credentials
| to the original service, I think it is implied that most
| victims would willfully provide their second factor, when
| asked for it.
|
| So, in case of phishing that's not the point. If you're
| actively logging in yourself a second factor doesn't
| prevent the attacker from gaining access.
| kevin_nisbet wrote:
| > Not if it also steals the 2nd factor.
|
| In Webauthn/u2f the 2nd factor is a proof that is unique
| against the particular site. So stealing the 2nd factor is
| significantly more difficult since it requires compromise of
| the computer/endpoint used to access the site to pass the
| wrong site to the hardware token, or cloning the physical
| device which should be tamper resistant (but not totally
| unheard of to clone some devices).
|
| Your statement is true for HOTP/TOTP based 2nd factor like
| google authenticator on a phone, although the stolen
| credentials shouldn't provide persistent access.
|
| And password re-use is still a problem if every service isn't
| covered by Fido2, but we need to start somewhere.
| np_tedious wrote:
| > persistent access
|
| Given a successful login and session, perhaps on some sites
| this is enough for passwords reassign via some backend
| (likely intended for mobile apps) API?
| lisper wrote:
| > The solution is to go only to the right site.
|
| i.e. blame the victim. This generalizes to: the solution to
| user error is for the user not to make errors.
|
| So no, that is not the solution.
| rdiddly wrote:
| Well, name one error that persists despite not making the
| error, and you can definitely say I'm wrong. But that
| wasn't the point. The solution is to go to the right site.
| You were supposed to use your imagination to come up with
| ways that might be caused to happen. The article and
| commenters here suggested password managers that
| discriminate between the right site and the wrong site,
| that's an example. "OH SURE BLAME THE VICTIM FOR NOT
| INSTALLING A PASSWORD MANAGER!" If you're looking for a
| solution that doesn't whatsoever require the participation
| of the user, you may meet with some degree of
| disappointment.
|
| There may be viable solutions that include still going to
| the wrong site, but I know for a fact that going to the
| wrong site does not happen if you go to the right site.
| It's a tautology just like your disingenuous Twitter-style
| reductionist accusatory re-interpretation of my comment
| suggests. Speaking of which, if you want to blame the
| victim, go right ahead (that was your idea), but I don't
| think the computer cares who gets blamed, unless and until
| it affects what gets typed in or clicked.
| scottLobster wrote:
| Actually better education and training is often the only
| real solution. It isn't "victim blaming" if the situation
| is at least theoretically within the victim's control. If
| some random "plumber" that I didn't call for shows up at my
| house, asking to be let in to replace some of my pipes, and
| I say "okay", then he robs me, is it victim blaming to say
| perhaps I should have been more suspicious of strange
| plumbers randomly showing up at my house to do work?
| lisper wrote:
| > education and training is often the only real solution
|
| No. That is _never_ the real solution. At best it is a
| necessary evil, but generally resorting to this is a
| reflection of a failure of imagination.
|
| The reverse authentication problem in particular is
| easily solved by the right UI design plus some improved
| infrastructure behind the scenes. Certificate pinning,
| for example, would help a lot. The hard part is not
| coming up with a solution, or even implementing it, but
| convincing everyone to adopt the solution because it
| doesn't help unless it is widely deployed.
| alisonkisk wrote:
| Explain how any solution prevents the user from opting
| out of yubikey and typing self-XSS into Dev console to
| get owned.
|
| Unless you have a 100% vendor controlled system, (more
| than Apple + ChromeOS combine) you have to rely on the
| user not breaking their own security.
| rdiddly wrote:
| If the easy part is the implementation and the hard part
| is convincing people of its value then I can say one or
| more of the following are true:
|
| - Your solution is not sufficiently great as to be self-
| evidently great.
|
| - People (i.e. the victim) must be faulted (i.e. blamed)
| for their inability to be convinced of its inherent
| majesty.
|
| - Given convincing's similarity and overlap both with
| educating and with training, you are having a failure of
| imagination. (Source: Your comment.)
| lisper wrote:
| The problem is that the people who need to be convinced
| are not the people who are being harmed by phishing. The
| people who are being harmed by phishing (non-technically-
| savvy end-users) are powerless. The people who need to be
| convinced of the merits of the solution are browser
| vendors and web site operators. Both groups would need to
| work together to solve the problem. Getting _that_ to
| happen is the hard part. It 's a very real problem, but
| it's a political problem, not a technical one.
| dathinab wrote:
| Not all 2nd Factor solutions allow stealing the 2nd factor.
|
| Mainly U2F incorporates the domain and (should) only work if
| an TLS connection with a valid certificate for given domain
| is used. Furthermore it uses a key exchange. This means:
|
| - The attacker needs a valid certificate for the applications
| login domain, which wrt. web security is normally assumed to
| not be possible but tbh. might be possible in case of an
| state actor or similar.
|
| - The attack needs to be live in the sense that password and
| 2FA auth needs to be directly forwarded to the attacked web-
| application and there it needs to trick any bot detection to
| make it believe it's not a bot. This also means even if they
| phish your authentication they only can use it once at the
| moment they phished you. But to e.g. then to disable U2F they
| often need to enter another password, so they need to phish
| you twice in a row, which is harder, but only slightly
| harder, tbh.
|
| - Alternatively they might hack the service and get their
| hands on the private webcertificate and clients private key
| if the service doesn't use a HSM for that. But that is
| normally much harder and for many attacks unfeasible (and
| there is normally little reason to phish if you can hack a
| server that deeply).
| shawnz wrote:
| The attacker could proxy the 2FA request from the real site
| using the password you enter and therefore you wouldn't be
| protected.
| cortesoft wrote:
| Right, they could have access to your account, but not full
| access. A good website will ask for 2FA again if a user tries
| to do something destructive (like change password, email, or
| disable 2FA). They wouldn't be able to do those things.
| [deleted]
| Spivak wrote:
| Yes, that's basically the author's point. But it does protect
| you against someone trying to use your password on another
| site.
| FeepingCreature wrote:
| Yes, you can MITM 2FA, but you can't timeshift 2FA.
| kube-system wrote:
| > 2FA absolutely will protect you from a phishing site using
| the password it stole.
|
| The author is pointing out that they will steal _both_ the
| password and your 2FA token.
| valvar wrote:
| While this is possible, it does require significantly more
| effort on the part of the attacker and there are many more
| points of failure. So I'm guessing most phishing sites don't
| actually do that, even though of course some do.
| ascar wrote:
| If you look at the context of the article, you should
| assume that phishing attack is sophisticated enough and
| responding to that attack with "you should use 2FA" is
| missing the point (which is exactly what the author
| claims).
|
| 2FA (at least the simple OTP variants) don't protect
| against phishing, they just protect against sloppy phishing
| attempts.
| kube-system wrote:
| All that is required is that they phish in real-time or
| automate the attack. These attacks are not uncommon in the
| wild. MITM'ing three fields in a login page is not much
| harder than writing two fields to a DB. And it's basically
| trivial to do it over the phone.
| bostik wrote:
| Phishing has been commoditised, the criminals don't write
| their own pages anymore.
|
| In fact the phishing toolkits have been doing TOTP
| passthrough/relay for a few years now. For the attacker,
| it's a nice feature: victim could be using SMS,
| authenticator app or even an out-of-band delivered token
| book - they are all captured and passed along equally well.
|
| U2F and FIDO2 with hardware keys are the only realistic
| safeguards. On the other hand, I do subscribe to the stated
| problem, because for most people they are a usability snag.
| The NFC variant has the potential to address this, though:
| instead of plugging a key in and touching the blinky
| button, you just wave your keyring next to the device. Too
| bad NFC readers are not universally available on phones,
| tablets or laptops.
| jfrunyon wrote:
| > The average YubiKey is PS50. There are a few around the PS30
| price point. That's a huge expense given the small number of
| sites that support them.
|
| A wide variety of sites support them. I'd estimate around 1/3rd
| of the services I use daily (both personally and for work)
| support them. (That said, I got mine for $30 by signing up for a
| magazine subscription, and wouldn't have paid significantly more.
| And, of course, some of my services have been chosen because they
| differentiated themelves from the competition by Yubikey
| support.)
|
| > Buy a device, register it, install the app, configure it, find
| the setting in the website, enable it, hope your machine has the
| right sort of USB ports, press the button at the right time.
|
| Except, with U2F, that's not true. It's just "buy a device, plug
| it in, find the place on the website, wait for a prompt, press a
| button".
|
| > Convenience. My YubiKey is on my keyring. My keys are in my
| coat.
|
| That's a pretty personal problem. For me, my keys are either on
| my belt loop or on my desk, which means it's always handy. Of
| course, you can also get one of the models which is designed to
| stay plugged in, if that is compliant with your threat model.
|
| > Risk. YubiKeys have no password lock of their own. ... if
| you've stolen my laptop and the YubiKey is plugged in
|
| True, which is why they're not generally suitable for standalone
| use; only as a second credential. Also, if your threat model has
| you worried about them being stolen together, simply don't leave
| them plugged in together.
|
| > Support. WebAuthn is a great standard - but only a few sites
| support it.
|
| That's still as false it was when it was your first point.
|
| > If fake-github.com said "Hmmm we're having problems with our
| WebAuthn backend - please use a one-time code from your
| authenticator app for added security" would you be fooled?
|
| At the very least, it would probably cause me to double-check
| that I was on a legit site.
|
| Overall: I don't think you give enough credence to the fact that
| it's real, secure, convenient 2FA. No more digging your phone out
| of your pocket, unlocking it, navigating to the app, and then
| setting your phone down so you can type in the code. And then
| locking your phone and putting it back away.
|
| Personally, my Yubikey goes into my laptop at the start of the
| work day (the first time I use it), and it doesn't come out until
| I'm done working (well, or if I need to use my keys). All I have
| to do is tap the button after I put my password in.
| niftich wrote:
| This is a good article about the weaknesses of the trust models
| of navigation on the web. The author uses a password manager that
| also fulfills the role of a personal 'have I seen this site
| before?' database, which helps them associate a URL to its
| conceptual entity, in their quest to determine if the site they
| visited was the site they intended to visit.
|
| In this exact form, this is a feature that's absent from
| mainstream browsers today. Because browsers do not have this,
| people instead turn to all sorts of other signals to judge the
| site's identity, but each one of those signals is designed for
| another purpose, and ought to not to be used directly by the user
| to make such determination. But no other signals are available,
| so they get used nonetheless.
|
| Some people look at the URL before clicking it, or the URL bar in
| the browser after they've already navigated to the site, and try
| to judge from the URL whether the site belongs to the entity they
| intended to visit. This is fallible for a bunch of reasons,
| including: (1) people often read visually instead of comparing
| codepoint-by-codepoint, so reading errors or homoglyph attacks
| are possible, and browsers can only meaningfully mitigate against
| the latter; (2) very few people keep a computerized allow-list,
| so they check against expectations in their head; and (3) some
| organizations will make use of domain names that greatly differ
| from their own name, which works contrary to the instinct of a
| URL-judging user who consider themselves 'cautious', and it's
| difficult to stay aware of all this.
|
| Some people look at the TLS certificate, and try to judge from
| the information displayed by the browser about the cert whether
| the site belongs to the entity they intended to visit. This is
| fallible for a bunch of reasons, including (1) DV certs only
| prove that someone (i.e. anyone) had control of the domain at the
| time near the cert's issuance, so its value as a trust signal to
| the user ought to be zero and immediately reduce to the prior
| case of mentally validating the URL by its character content; (2)
| EV certs validate against a legal entity in some jurisdiction,
| but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-
| by-juristiction registries of legal entities are a tool for a
| different use-case and were never intended to collectively ensure
| globally unique Organization names; and (3) in their rush to
| ensure widespread TLS deployment on all sites, and their
| involvement with efforts to bring short-lived cost-free DV certs
| to everyone, browser-makers began de-emphasizing the UI
| distinctions between DV certs and EV certs some time before the
| true shortcomings of EV as a user-facing trust signal were widely
| demonstrated.
|
| Some people look for the visual design of the website. This is
| trivial to fake.
|
| Some people will rely on browser-resident bookmarks, browser
| history, or 'top sites' tiles to navigate to common sites they've
| visited before (or to sites the browser-maker pre-loaded into the
| listing). This is a great way to preserve the trust chain and
| reduce the likelihood that the user arrives at an unintended site
| by mistake. But these features do not directly address the case
| of a person navigating to a URL they were linked or provided from
| an arbitrary source, such as the example raised in the article.
|
| Building blocks exist today that could be used by publishers and
| browser-makers to aid users in judging URLs. Some of these will
| require past UX decisions to be undone.
|
| For example, top sites could become their own Root Certificate
| Authorities [1] and be listed in browser trust stores; these
| companies would be expected to issue certs for sites associated
| to themselves. This would eventually reshape the cert landscape
| so that a parent-child relationship between issuer and subject
| could be meaningfully distinguished from a 'provider and
| customer' relationship. Companies that provide services to
| others, such as payment processors, could also become root CAs
| and sign for their customers. These changes, and a browser UX
| that once again shows the cert issuer, would go a long way
| towards reducing the likelihood that users are fooled by sites
| trying to impersonate top sites.
|
| If this were to come to pass, other CAs would be expected to
| pivot to minting certs that play the role of a trustmark, by
| conferring a degree of ongoing assurance that's useful to the
| user (which, in fairness, was the original point behind EV
| certs). They would do this by establishing strong brands around
| their trustmark, issue certs for a short lifetime, and monitor
| the site on an ongoing basis to see if it's still deserving of
| their trustmark. This would result in a business model similar to
| those of EV certs, but a trust model that's based on the user's
| trust in the CA's exercise of good judgment befitting their
| brand.
|
| [1] https://news.ycombinator.com/item?id=13495262
| nyanpasu64 wrote:
| "Security Key by Yubico" is significantly cheaper than YubiKey,
| and supports open-source protocols ("U2F and FIDO2/WebAuthn") but
| not corporate 2FA protocols. It doesn't address the
| keychain/password issues though.
| underdeserver wrote:
| The author recommends BitWarden, but it seems like it's run by
| one guy. How do I know he doesn't go away? Get hit by a bus?
| t0astbread wrote:
| You don't but any good password manager should have an option
| to migrate away from it quickly.
| yumraj wrote:
| run your own instance of Bitwarden.. there's a nice dockerized
| server available written in Rust
| lifeisstillgood wrote:
| >>> The top result on Google is invariably an advert for a scam
| site.
|
| Wait what now?
| _wldu wrote:
| Nice blog post with interesting views.
|
| I leave my YubiKey plugged in all the time. It's basically a
| permanent part of the computer.
| nijave wrote:
| Same, and many websites have support for multiple keys so
| enroll a couple of the cheap $10 ones (per device) and then you
| can use TOTP or just printed codes as a backup.
|
| Even if your device is stolen 1) it's unlikely by a technically
| savvy bad actor (and if you're at risk, you probably have had
| special data security training anyway) 2) you're still only
| stealing one factor. Your device should also be encrypted with
| a password which would protect any passwords [managers] on the
| device
| cordite wrote:
| I recently experimented with the Yubikey OTP feature. Like TOTP,
| it can be proxied through as there's no challenge that includes
| signing the website name like FIDO. Also.. The Yubico OTP feature
| types using QWERTY with letters and no numbers. As I use dvorak,
| this resulted in considerable confusion as two yubikeys behaved
| the same.
|
| Interestingly, copying the credentials between Yubikeys will not
| result in an accepted yubikey OTP. The serial seems to be used
| somewhere in the calculation.
|
| A yubikey, using the CLI tool, can have TOTP credentials stored
| inside. This can be used in conjunction with grep and sed for any
| CLI scripts that may interactively request a TOTP.
| bombcar wrote:
| 2FA prevents harvesting of passwords - but it just means that
| they have to be actively (or programmatically) attacking
|
| I suppose if they AlSO have protections against proxying (forbid
| more than X login/login attempts from a given IP) it might help -
| but certainly not against spearphishing. Honestly don't see how
| you can protect against even moderate level spearphishing
| reasonably.
|
| Some banks have a "word" or picture you select that they'll show
| you durning login - never understood how this can't just be
| proxied.
|
| Certificate based authentication in theory allows both sides to
| Authenticate the Other.
| edent wrote:
| > Some banks have a "word" or picture you select that they'll
| show you durning login - never understood how this can't just
| be proxied.
|
| It can, simple as that. Some make it moderately more difficult
| by showing you, say, 9 pictures and asking you to pick the one
| that's yours. But, again, dead easy to proxy.
| isbvhodnvemrwvn wrote:
| Others also ask you to put in only some characters of your
| password, which is even more troubling because at best they
| hash them in various configurations when you change password,
| at worst - they keep it in plaintext.
| jameshart wrote:
| The original version of this pattern relied on local storage
| on your device to ensure that only the real site or app could
| show you the right image.
| bombcar wrote:
| That makes a lot more sense - I wonder if any are left that
| do it.
| PascLeRasc wrote:
| That's a really good idea, we should be asking sites to verify
| themselves with a second factor. Do you know if that's in use
| anywhere?
| MayeulC wrote:
| With PAKE schemes such as OPAQUE, you verify the site as
| well, IIRC, and that can be used to derive a shared secret, I
| think.
|
| It is my understanding that U2F and Webauthn can't be proxied
| either, but I forgot the specifics and would appeciate if
| someone could enlighten me.
|
| Conceptually, you just have to generate a keypair using
| Diffie-Hellman, and sign a challenge after the session has
| been opened, so that the server can double-check you have the
| right key (it already has your public key).
| tialaramex wrote:
| In WebAuthn (and U2F but that's obsolete and you should
| just implement WebAuthn on a green field system) your
| credentials are inherently tied to an FQDN yes.
|
| There are two tricks involved. Firstly, your web browser is
| co-opted to do this work. It knows this is
| news.ycombinator.com much better than you do. If this
| wasn't in fact news.ycombinator.com, but looked correct and
| behaved as expected, you likely would not notice, but the
| browser checks the name matches for every single individual
| HTTP transaction.
|
| So if the site fakebank.example tries to do a WebAuthn
| validation for realbank.example it just plain doesn't work.
|
| Next, for a Security Key or similar FIDO1 device, where you
| can enroll an unlimited number of sites on a single
| authenticator since they aren't actually stored on the
| authenticator - the keys used are encrypted with that FQDN.
| So if bad guys stole your real authentication database
| enties at Real Bank (maybe from a backup) they not only
| can't use them, they can't even play them back to you and
| have you use them - they only work at all on the real site
| they were for, they're just random garbage on any other
| site.
|
| This relies on a two encryption technologies. 1. Public Key
| Signatures (mostly using elliptic curves but that isn't
| essential). I can pick two related numbers, tell you one,
| and then in future you can challenge me to prove I know the
| other one on different occasions, and you'll know I do even
| though you don't learn the number. Your Security Key can
| prove to GitHub that it is still the same Security Key that
| visited before, despite GitHub not knowing which one that
| is.
|
| 2. AEAD Authenticated Encryption. Modern symmetric
| encryption not only keeps your data confidential, it can
| also simultaneously authenticate it, your Security Key
| knows when given back an encrypted "ID" that it's a real
| one it issued to this web site, because random IDs will
| fail the authentication step.
|
| _Either_ of these tricks would arguably achieve our basic
| security goals, but they are both adding further strengths
| to the system, so why not have both.
|
| [Edited to clarify some details]
| _wldu wrote:
| This is called a site key and was made popular by Bank of
| America. I'm not sure if they still do it.
|
| https://en.wikipedia.org/wiki/SiteKey
| tialaramex wrote:
| > Honestly don't see how you can protect against even moderate
| level spearphishing reasonably.
|
| WebAuthn. The article author dismisses it as basically too
| inconvenient (they apparently keep their Security Key somewhere
| out of reach and they struggle to remember the complicated user
| interaction of... pressing a button)
|
| But WebAuthn is completely effective against phishing.
|
| The closest to plausible attacks are: The bad guys take over
| the target servers (no reason to phish you); The bad guys
| persuade you to physically send them your authentication device
| (truly not everybody can be helped...); The bad guys persuade
| you to install software under their control on a general
| purpose PC (this won't work on a Phone) and then you follow
| their bad instructions to "use" your authenticator with their
| software to get them in.
|
| Mutually authenticated TLS is in principle viable, and I have
| used it in machine-to-machine systems, but the UX is atrocious
| and it has grave privacy problems.
| guenthert wrote:
| I think the conundrum is that such a device uses either a
| simple UI (like pressing the button), which then is unable to
| convey to the user which transaction is to be signed off on
| (the desktop/laptop/phone might be compromised) or the device
| has its own display and multiple-choice input that'll be too
| expensive and cumbersome for all to carry around all the
| time, everywhere.
| dgudkov wrote:
| They author makes a few good points, but I find the author's
| critique of Yubikey weak:
|
| >Cost. The average YubiKey is PS50...
|
| If that's too expensive for ensuring your internet security, then
| either you underestimate the risks, or undervalue your
| information. If a Yubikey cost 10 times more it would still be a
| bargain.
|
| >Usability. Buy a device, register it, install the app, configure
| it, find the setting in the website, enable it, hope your machine
| has the right sort of USB ports, press the button at the right
| time.
|
| Pressing the button at the right tight was a joke, right?
| Although, I admit it may be challenging for people with
| disabilities. Websites making it hard to find 2FA settings is not
| a Yubikey's problem, it's a website problem. Setting up a Yubikey
| is rather straight forward too. The main issue is the inability
| to clone a Yubikey programmatically, but that's the price of
| security.
|
| >Convenience. My YubiKey is on my keyring. My keys are in my
| coat...
|
| That's can't be serious too. I won't even elaborate on this.
|
| >Risk. YubiKeys have no password lock of their own. At least my
| crumby Android has a fingerprint lock to prevent people getting
| my 2FA tokens. But if you've stolen my laptop and the YubiKey is
| plugged in, then you've got the keys to my kingdom.
|
| That's actually the only valid point I somewhat agree with.
| Again, this is largely mitigated by developing the right habits.
| You don't leave your car keys hanging in your car's lock after
| leaving the car in a parking lot, right? Then why do it with
| Yubikey? If developing a new _minor_ habit represents a problem,
| then either you underestimate the risks, or undervalue your
| information.
|
| An additional password/fingerprint protection would be nice
| though. I agree on that.
|
| >Support. WebAuthn is a great standard - but only a few sites
| support it...
|
| Again, this is not a Yubikey's problem. It's a website problem.
| csydas wrote:
| I mean, you say all this, but more or less these are the same
| complaints I hear from even seasoned IT professionals every
| single day when it comes to security.
|
| Even the "the key is in my coat" is not a joke at all -- I've
| had clients who got compromised by a malicious insider because
| some admin wrote passwords on a sticky note simply because
| "password managers are cumbersome".
|
| I get what you're saying on each point, but understand that
| security is as much about discipline as the actual security you
| implement. You can have the best of the best, but it doesn't
| mean anything without the discipline to use it, and I suppose
| that's what the author is trying to convey.
|
| You even touch on it in your response about developing the
| right habits, and that's the author's port -- without
| discipline, the Yubikey means nothing.
|
| >Again, this is not a Yubikey's problem. It's a website
| problem.
|
| On this point I can't really agree at all; Yubikey might have a
| solid solution for a problem, but if no one is implementing it,
| then it's a solution looking for a problem. The mythical
| "average user" won't be persuaded to drop any amount of money
| on a dongle that does nothing; if it doesn't work for a large
| majority of their most common sites, then it's just a waste of
| money.
|
| I'd suggest it __is__ Yubikey's problem as they're not
| promoting their value to sites in a way that implementation is
| a no-brainer. Checking on their compatibility list fo common
| chat-applications, common forums, common message
| boards/imageboards, and common shops world-wide, the adoption
| is very limited. Surely the admins of popular sites are aware
| of Yubikey, but at some point there was a decision not to add
| functionality -- Yubikey needs to make the efforts to promote
| adoption and figure out where there resistance comes from.
|
| Of my daily sites that I might expect to be aware of/implement
| some hardware security, only reddit is on the list of "works
| with Yubikey", and I pretty rarely use reddit. Listing sites my
| friends and family use on a day to day basis, only Google
| Accounts comes up.
|
| That's what the post is talking about. Yubikey does not have
| the penetration to be viable to "average users", and even for
| tech persons, the device is useless without the discipline to
| adjust habits in the first place, which most people just don't
| have.
| dgudkov wrote:
| >security is as much about discipline as the actual security
| you implement
|
| Totally agree on that. The author's main ranting about
| Yubikey is that it requires developing new habits, but that's
| exactly the point.
|
| >they're not promoting their value to sites in a way that
| implementation is a no-brainer.
|
| That's a good point. Although, poor adoption of hardware
| tokens even by banks (e.g. no bank in Canada supports
| Yubikey) is surely not because it's hard to implement. It's a
| "chicken-or-egg" problem. Organizations don't support
| hardware tokens because few people use them, and few people
| use tokens because many organizations don't support them
| anyway. Yubikey and other hardware token vendors could've
| done a better job promoting and simplifying using hardware
| tokens.
| xondono wrote:
| Just because it's _a website problem_ , it doesn't stop being a
| problem.
|
| Usability is important if you want adoption outside of the HN
| crowd.
| dgudkov wrote:
| It is a problem anyway, I agree. It's incorrect to attribute
| the problem specifically to Yubikeys.
| acupofnope wrote:
| > YubiKeys have no password lock of their own
|
| I don't know if the author of the blog post means something
| else but if you're using 2FA tokens (i.e. Yubikey
| Authenticator) you _can_ put password protection for additional
| security.
| mynameisvlad wrote:
| In some scenarios, Windows 10 will also require a PIN to use
| a key:
|
| https://docs.microsoft.com/en-us/azure/active-
| directory/user...
| TACIXAT wrote:
| This is a weird post. Yubikeys are absolutley the solution here,
| also a password manager. A decent password manager will check the
| URL for you.
| chungy wrote:
| There are many legitimate situations in which a login domain is
| changed and a password manager no longer works. So then you
| manually open the password manager, look for the password,
| copy+paste, and save the new entry.
|
| How can you be completely confident that this isn't an
| attacker?
| tialaramex wrote:
| Right. One of the _good_ decisions in WebAuthn is that this
| type of nonsense simply isn 't possible. It's designed so
| that you can't do this. When the big boss absolutely insists
| that ourcorp.example must rename to xp4ifis.example because
| of whatever nonsense, there's nothing to argue about, it
| won't technically work, it can't be done. Like if they
| decided it would be better branding if up was down, too bad.
|
| In almost all cases these were just about vanity (e.g. the
| university where I studied and had some of my first jobs
| renamed itself and gave every web site new URLs, purely out
| of vanity, at considerable cost with no benefit) and so when
| they discover it can't be done technically they just give up
| and continue to use the old name for authentication, meaning
| your security posture is intact. In the few other cases
| you're now going to have to have a conversation with your
| users about why you broke everything and need to begin over.
| I sure hope the gain to your organisation was worth it.
| guenthert wrote:
| Not too long Scottrade (2 or 3 't'?) got bought by
| Ameritrade. All Scottrade accounts are now accessed
| exclusively under the new domain name.
|
| Recently Ameritrade and Charles Schwab Corp. merged ...
| TACIXAT wrote:
| In that rare case you just check the URL. Contact the company
| if it is a high value login. You can also verify by searching
| for the site and clicking through to see what their webpage
| offers as ground truth.
| smokey_circles wrote:
| No.
|
| 2FA is designed to authenticate that this _is_ you logging in.
| Wrong off the bat.
|
| The "they just use your login token" is akin to "they just hacked
| the CIA's database". _Just_.
|
| I also don't see how the author thinks that the same users who
| struggle with yubikey won't simply search for the github.com
| login on githud.com in their password manager. Bitwarden and co
| are great but the default domain creates a problem where
| login.signup.domain.com does not match login.domain.com and so
| users are used to searching.
|
| The bit that completely lost me was the lamenting of convenience
| with the YubiKey.
|
| Security and convenience are polar opposites.
|
| Coupled with the "tech bros" comment, I am not sure this is in
| good faith at all
| paraknight wrote:
| > The "they just use your login token" is akin to "they just
| hacked the CIA's database". Just.
|
| He's saying that they can basically MITM you, which is true.
| GitHub asks attacker for token, attacker asks you, attacker
| gives token to GitHub on the spot, presto.
| smokey_circles wrote:
| Ah, I did overlook that one.
|
| That said: I remain unconvinced that 2FA is a trivial thing
| to beat. Now we're talking about an active attempt to
| impersonate _you_ , as opposed to a general catch-all-
| the-2fa-less-logins
|
| Put another way: If you ran this phishing site, would you
| focus your time on the logins with 2FA enabled (which if I've
| understood correctly means you'd have to catch them in the
| window the token is valid for) or the logins without?
| TheGeminon wrote:
| If you use your phished credentials immediately (e.g.
| inline with it being phished), then it doesn't make a
| difference if they are using 2FA. You use the credentials
| they entered to login from a backend system automatically,
| and then if that ends up with a 2FA prompt, you show the
| victim the 2FA phishing page next, instead of redirecting
| them to the real app/whatever.
|
| This obviously does have its own downsides (you have to
| maintain a login infrastructure, as well as your phishing
| infrastructure), but this was even seen before 2FA became
| common to detect if an incorrect password was entered into
| the phishing site.
|
| It is definitely an improvement, but TOTP doesn't provide
| much protection from phishing, and as it becomes more
| popular more phishers will need to accomodate for them in
| their campaigns, further reducing their effectiveness here.
| sulam wrote:
| > 2FA is designed to authenticate that this is you logging in.
| Wrong off the bat.
|
| Pretty sure you are in agreement with the post here. IOW, 2FA
| _isn 't_ to authenticate the site.
|
| Most of 2FA I use won't help you assuming the credentials I
| just gave the phishing site are immediately forwarded to the
| real thing. I will see a login verification, just like I
| expected, from the site I expected it to come from. Maybe, just
| maybe, I might notice that the login _location_ is not where I
| am, for 2FA implementations that tell you that.
| smokey_circles wrote:
| I might be, I took the article at it's title to mean "2FA
| does not protect you from your password being leaked"
| GolDDranks wrote:
| Let's say I've got 2FA enabled. I get a confirmation link to my
| e-mail. I click the link. Because the e-mail is sent by the real
| site, the link leads to the non-phishing site. The scammer has my
| password, but is still unable to access the site. How does that
| not help?
|
| Of course if it's a 6-digit code or something, then they are able
| to stole my it like they did with the password.
| jakelazaroff wrote:
| I wouldn't call sending codes by email "true" 2FA, though,
| since your email address can also be used to reset your
| password.
| goodpoint wrote:
| Another aspect that people always forget is that 2FA protects
| only the _login_ process.
|
| Any successful attack against your browser (or any other
| application on your workstation) allows the attacker use existing
| and future browsing sessions.
|
| The attacker can simply wait until you log onto your bank account
| and remotely control your browser.
| janwillemb wrote:
| +1 for bitwarden as password manager. It did indeed save me a few
| weeks ago from a phishing attempt. After reporting it to my
| employer and warning all my colleagues it turned out to be the
| tech department doing a white hat test to educate the employees
| :)
| yangwuzrite wrote:
| The author of this article has no idea how 2FA works or why it's
| used.
|
| 2FA is used to prevent or mitigate the impact of phishing or
| other attacks where a password is compromised (password reuse,
| random guessing, keylogger, etc.). The author does bring up one
| hypothetical attack -- a man-in-the-middle attack -- where
| someone can trick a user into providing their 2FA or triggering
| an authorization (like with a Duo push). This requires the
| ability to execute a real-time attack.
|
| FIDO/U2F/Webauthn (I still haven't figured out exactly what
| you're supposed to call them) security tokens solve that use case
| by allowing the website to authenticate directly to the token.
| That can't be phished -- even if you're tricked into a fake
| website and given a fake webauthn prompt, AFAIK there's no known
| way to proxy or otherwise intercept that second factor
| authentication to allow a phishing attack to succeed.
|
| His complaint that the token doesn't have a password is largely
| pointless -- the token is the second factor, the password on the
| site is the first. If you're using passwordless FIDO2 logins,
| then it does have a PIN.
|
| Long story short, this guy is full of crap.
| fastball wrote:
| > The top result on Google is invariably an advert for a scam
| site.
|
| Um... no?
| edent wrote:
| Try browsing the web without an ad blocker. The top results on
| Google search are always adverts. And, quite often, they link
| to scam sites.
|
| There are loads of copycat websites which appear in the top
| slot - especially for government site.
| https://www.which.co.uk/consumer-rights/advice/how-to-spot-a...
|
| It's particularly prevalent in the UK, where you see companies
| proxying legitimate services and charging premium rate for
| phone calls -
| https://www.theguardian.com/money/2017/feb/04/beware-call-co...
| fastball wrote:
| Can you give me an actual example of this with a google
| search right now?
| iso1210 wrote:
| I just did an ingonito search for "!g ETA",
|
| I got 3 results on the screen
|
| CanadianTravel - ETA Ad*www.canadaonlineapplication.org/
|
| CanadianTravel - ETA Ad*www.canadatravelvisa.com/
|
| CanadaETA - for UK citiziens - canadian-etavisas.com
| Ad*www.canadian-etavisas.com/
|
| Which all look the same, and seem to charge $99 for the
| 'service' of filling in a form the Canadian government
| charges $7 for.
|
| After that there is a wikipage for the Spanish terrorist
| group, two more wiki pages, then finally
|
| The official site: Electronic Travel Authorization (eTA):
| How to apply - Canada.ca
|
| Searching google for "Canada ETA" gives the above 3 adverts
| and also a link to https://www.etatocanada.com/ which
| charges PS69 for the service.
| fastball wrote:
| So.... not a scam, in that you get exactly what you pay
| for. And certainly not phishing, which this article was
| talking about.
| DanBC wrote:
| In the UK there was a problem of commercial companies
| setting up look-alike websites and charging a fee to do
| stuff that is free to do via the correct gov website. It's
| not as common now, partly because UK orgs put pressure on
| Google to fix it.
|
| Here's an example:
|
| [change name deed poll]
|
| https://www.google.co.uk/search?sxsrf=ALeKk00J9KQR_SH1ZlvHg
| i...
|
| For me the top four links are clearly marked ads. (Although
| some people may miss that [ad] marker). After the ads there
| are two links to the proper gov.uk website. Then there's a
| link to a commercial site called "Deed Poll Office", who
| charge for a services that's free.
|
| In the past that TheDeedPollOffice link ranked higher.
|
| Similar things used to happen for passports and tax self
| assessment.
| Blikkentrekker wrote:
| How can this pass through _Google_ 's quality controls that
| scam sites can get advertising?
| proactivesvcs wrote:
| ...quality controls? They're paying customers, Google has
| no incentive to prevent scam sites, which is why the
| results and adverts are infested with them, and have been
| for decades.
| Blikkentrekker wrote:
| It seems to be against _AdSense_ 's rules, however.
|
| Apparently they aren't so enforced.
|
| Good thing that Google is still going after you if your
| website has nudity on it it, however. -- 'tis very
| important.
| jeffbee wrote:
| That is quite incorrect. Google has more incentive than
| anyone else to deliver only the best results and ads to
| searchers. Delivering them to scams harms their
| reputation and would eventually erode the CTR.
| as300 wrote:
| Correct me if I'm wrong but I've seen oauth implementations that
| require you to be redirected to the site you're giving
| credentials for to finish the flow of authentication. Wouldn't
| this make it a lot easier to determine that you're being phished,
| if you have to go to a whole different web site that warns you
| that you are giving external parties access to your credentials?
| anticristi wrote:
| Indeed, using OAuth everywhere would make the success of such
| an attack less likely. However, I feel strongly about not
| letting a single organization act as my identity provider. I
| don't like putting all eggs in the same basket.
| anticristi wrote:
| Time to implement Password Authenticated Key Exchange, e.g.
| Secure Remote Password, in the browser?
|
| Here is what I suggest. Let there be a field <input type=pake
| challenge=blah />. Whatever is typed into that field is
| unavailable to the front-end code. Instead, the browser computes
| a one-way function of the password, challenge and origin, and
| makes _that_ available to the front-end.
|
| The devil is in the details, but I'm pretty sure that a robust
| security analysis could eventually produce a solution that allows
| any user to type any password in a "super-password" field, and
| rest assured that the phishers are out.
|
| The next issues would be: - How to prevent "downgrade" attacks,
| i.e., the user should immediately notice if a legacy password
| field is used. - How to convince the Internet to adopt this.
| flas9sd wrote:
| for one, html email is vicious, terminal email clients can help
| to not fool you with visual alignment.
|
| I like the feature `From: <> via <>` in the view, maybe this
| tipped her off - "palette.cloud" is an unlikely envelope-sender
| for github mail. Reactivating an old gmail account, I can't see
| how to enable the feature.
|
| In a muttrc, you can get context with showing you more headers.
| ignore * unignore from: to: cc: date: subject: user-agent:
| x-mailer: return-path: authentication-results: hdr_order
| date: from: return-path: to: subject: user-agent: x-mailer:
| authentication-results:
|
| A client could by default show "unverified" and use spf+dkim to
| get to verified. The "unverified" could be signal enough to
| enable spidey sense
| dathinab wrote:
| I think password managers are the first step you should take and
| FIDO/U2F hardware keys are the second similar important step.
|
| With that even if your password manager get hacked you still have
| a secure account as they didn't got the U2F at the same time a
| password manager is a must have as it's prevents a lot of
| phishing attacks from even getting any chance and is quite
| convenient, too.
|
| The problem with hardware keys is that for many people they are
| not so easy:
|
| - You MUST generate and safely store recovery keys, storing them
| in your password manager is suboptimal, but better then not
| having them. (Not having them means potentially losing account
| access permanently.)
|
| - You often need to enable it.
|
| - You should store it with your keys, which dependent on habit
| might not be around your PC (in my case they always are in my
| pocket so :=) ).
|
| - If your site doesn't support U2F/FIDO you might need an
| additional phone + app, or laptop app to get the numbers out of
| your key.
|
| So while I think it's a must have for every developer to have a
| hardware security token lie a Yubikey it's not something I could
| convince e.g. my Dad or Sisters to use.
| slaymaker1907 wrote:
| 2FA can actually prevent phishing, though it requires close
| integration with the app and the authenticator. It's actually
| quite similar to CSRF prevention. On the site itself, display a
| random nonce to the user for confirmation then send an request
| for authentication to the authenticator with said nonce which the
| user can confirm. The battle.net authenticator does this.
|
| For added protection, you can prompt the user to select which
| nonce is correct to force them to verify it is correct. The
| Microsoft authenticator does this sometimes.
|
| The downside of this approach is that it requires a constant
| connection between the second factor the service. It also relies
| on the fact that the service authenticates itself via TLS or some
| other means, though that is a relatively minor issue.
| yumraj wrote:
| There is another issue, I think, with Cloudflare serving in the
| middle.
|
| For many websites the Cert is owned by Cloudflare and shows
| Cloudflare as the _Organization_ and not the website owner. In
| that case there is no way for me to figure out whether I 'm on
| the actual site or a phished site.
|
| For example see this (it is the Visa opt-out website that was
| posted a few days ago on HN):
| https://marketingreportoptout.visa.com/OPTOUT/request.do
|
| Supposedly the above it authentic, but the Cert is showing
| Cloudflare as the Organization. Now unless the claim is that
| Cloudflare will never serve phished websites, which I doubt
| unless Cloudflare is doing a human validation for each client,
| this is a problem.
| invokestatic wrote:
| This is an issue with any domain-verified TLS certificate,
| which make up the overwhelming majority of certificates in use.
| Only CAs which offer organization-verified (OV) or extended-
| verified (EV) certificates, typically at exorbitant prices,
| does the TLS certificate attest the publisher of the website.
| yumraj wrote:
| > Only CAs which offer organization-verified (OV) or
| extended-verified (EV) certificate, typically at exhorbitant
| prices, does the TLS certificate attest the publisher of the
| website.
|
| Even so, I'll expect financial institutions to have that.
|
| Note: I'm not saying the above is a Cloudflare issue, perhaps
| someone at Visa was being stingy - I'm just saying it's an
| issue and would be bad if that becomes the mainstream.
___________________________________________________________________
(page generated 2021-01-17 23:00 UTC)