Slashdot Mirror


Android Is Helping Kill Passwords on a Billion Devices (wired.com)

The FIDO Alliance -- a consortium that develops open source authentication standards -- has been pushing to expand its secure login protocols to make seamless logins a reality for several years. Today, it has hit the jackpot: Google. From a report: On Monday, Google and the FIDO Alliance announced that Android has added certified support for the FIDO2 standard, meaning that the vast majority of devices running Android 7 or later will now be able to handle password-less logins in mobile browsers like Chrome. Android already offered secure FIDO login options for mobile apps, where you authenticate using a phone's fingerprint scanner or with a hardware dongle like a YubiKey. But FIDO2 support will make it possible to use these easy authentication steps for web services in a mobile browser instead of laboriously typing in your password every time you want to log in. Web developers can now design their sites to interact with Android's FIDO2 management infrastructure.

123 comments

  1. No way to re-secure your body by Anonymous Coward · · Score: 5, Insightful

    Biometrics can be stolen or faked. But there's no way for the legitimate owner of that body to replace them when that happens.

    (posting this on the day my office is forcing a periodic password change on me)

    1. Re:No way to re-secure your body by Oswald+McWeany · · Score: 1

      Biometrics can be stolen or faked. But there's no way for the legitimate owner of that body to replace them when that happens.

      (posting this on the day my office is forcing a periodic password change on me)

      Yes, because whatever biometric data is read- it is converted to some digital format. That digital format is then no different than a password- probably a lot longer, but if you can steal that array of data, you can copy it and send it from any device you desire.

      --
      "That's the way to do it" - Punch
    2. Re:No way to re-secure your body by Anonymous Coward · · Score: 0

      By "kill passwords", they probably just mean not having to use them in normal circumstances. The possibility of using passwords will remain to login in case your biometrics are damaged, and you could revert to password-only in case your biometrics are stolen.

    3. Re:No way to re-secure your body by Anonymous Coward · · Score: 0

      Correct.

      However missing the point. There are millions of websites out there that you have to create login's for, and they have arcane password rules that are inconsistent.

      The most important stuff, you will create a password that only you will know (eg your primary email, your work email, and your bank/government accounts) everything else, like forum and game logins are trivial things that at worst, if someone stole an easily guessed password, is more the site/game's problem than yours. eg Square-Enix's site is hot garbage for two-factor login but it works. I would still never buy anything off of it if it requires saving a credit card.

    4. Re: No way to re-secure your body by OneOfMany07 · · Score: 1

      Why would you send a fingerprint? Wouldn't you use that to send a secure token? After unlocking the local method of building said token.

      Think you guys need to go put on the tinfoil hats again. Smart people are on it for you. Or go help fix the broken specifications none of us have read.

      Oh and go read that "New LG hand blood vessel security on G8" release from just a bit ago. It has a sensor that includes depth so scotch tape won't work (no 3D ridges). Yes people will find ways to break in eventually, and they'll add better ways of detecting. And combine multiple methods.

    5. Re:No way to re-secure your body by Anonymous Coward · · Score: 0

      So don't use biometrics. Use a keycard instead.

    6. Re:No way to re-secure your body by Zmobie · · Score: 1

      While true, doesn't actually matter entirely in this case. Since FIDO allows you to use whatever you want on your side for authentication (Key card, biometric, password probably, etc.) you can change it or not use it at all. The challenging party doesn't even get access to what method you used for authentication locally, that never leaves the device. The difficulty to steal that data then becomes all of the hidden juicy bits are on user devices that an attacker would need to compromise individually.

    7. Re: No way to re-secure your body by Anonymous Coward · · Score: 0

      FIDO wants to use Paw prints

    8. Re:No way to re-secure your body by Anonymous Coward · · Score: 0

      If it requires saving a credit card to create an account it's already a "piss off retards" situation.

    9. Re: No way to re-secure your body by Anonymous Coward · · Score: 0

      The point is that it is relatively easy to change something you have or know, it is vastly harder to change something you are. While the last one is more foolproof for the user, it is also more catastrophic when the credential eventually gets compromised (which it will).

  2. You mean, like iPhone already does? by Anonymous Coward · · Score: 0

    I've had this on my iPhone for years already.

    1. Re:You mean, like iPhone already does? by DontBeAMoran · · Score: 1, Insightful

      No, because your iPhone works with regular login forms.
      Which is, of course, the proper way to do it.

      --
      #DeleteFacebook
    2. Re:You mean, like iPhone already does? by Anonymous Coward · · Score: 0

      I'm not being funny like, but have you ever used an iPhone?

      You just put your finger on the Home button and it works. No form filling necessary. Super easy, barely an inconvenience.

    3. Re:You mean, like iPhone already does? by supremebob · · Score: 1

      Umm... the browser on the iPhone stores credentials for you and automatically authenticates using Face ID or Touch ID if you have it configured.

      I'm not sure why wouldn't configure such a feature if available. Any decent password that's worth a damn (mixed case, numbers, punctuation, more than 8 characters) would be a pain in the ass to type on a mobile device keyboard.

    4. Re:You mean, like iPhone already does? by DontBeAMoran · · Score: 1

      I have used three iPhone models so far. None had a finger scanner.
      Yes, I'm still using an iPhone 4 in 2019. If you have a newer model to give me for free, I'll take it.

      --
      #DeleteFacebook
    5. Re:You mean, like iPhone already does? by Anonymous Coward · · Score: 1

      I have used three iPhone models so far. None had a finger scanner.
      Yes, I'm still using an iPhone 4 in 2019. If you have a newer model to give me for free, I'll take it.

      That didn't seem to stop you from authoritatively trying to explain how new iPhones sold in the last 8 years work. Explaining in a completely incorrect way I might add.

    6. Re: You mean, like iPhone already does? by reanjr · · Score: 1

      The difference here is that you are giving your passwords to Apple and have to trust them to secure it. With the Android solution, you don't have to trust Google.

    7. Re:You mean, like iPhone already does? by mattyj · · Score: 1

      How does that thing even turn on any more?

    8. Re:You mean, like iPhone already does? by DontBeAMoran · · Score: 1

      With the power button, as always.

      --
      #DeleteFacebook
    9. Re:You mean, like iPhone already does? by DontBeAMoran · · Score: 1

      You say I'm incorrect but a lot of posters say it works exactly that way. So either we're all wrong, or you are.

      --
      #DeleteFacebook
    10. Re:You mean, like iPhone already does? by DontBeAMoran · · Score: 1

      The browser on the iPhone stores credentials for you and automatically authenticates using Face ID or Touch ID if you have it configured.

      And how is that different than "works with regular login forms" exactly?

      --
      #DeleteFacebook
    11. Re:You mean, like iPhone already does? by david_thornley · · Score: 1

      Unless it's my finger, in which it works maybe once a year. I turned off fingerprint unlocking because it isn't saving me any time or hassle and while turned on there's a bare possibility that someone could turn on my iPhone when I don't want them to.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  3. Insecure by Anonymous Coward · · Score: 0

    Weakest link in chain, one password to rule them all, insufficient endpoint security, biometric data is not authentication, etc. Good luck with losing all your data.

    1. Re:Insecure by Zmobie · · Score: 1

      Technically yes, but with this method attackers have to compromise each device locally in order to get that kind of data. I could also see authentication 'partitions' being used such that if there were a compromise it takes multiple points of knowledge to unlock different partitions. If one were so inclined you could also use an external device as the authentication method that would also need to be compromised and even hold some of this information on different devices so that in no instance are all eggs in one basket.

      After reading up on the standard I am actually a fan of the design. Lets face facts, passwords have been outdated for some time.

  4. Web developers by DontBeAMoran · · Score: 2

    Web developers can now design their sites to interact with Android's FIDO2 management infrastructure.

    How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?

    --
    #DeleteFacebook
    1. Re:Web developers by The-Ixian · · Score: 2

      Why would you not choose a new method if it is more secure and you can also have it in place at the same time as normal passwords?

      Nobody is suggesting that this be a mutually exclusive choice for web developers.

      By your argument, we would never be able to change anything once it was deployed...

      --
      My eyes reflect the stars and a smile lights up my face.
    2. Re:Web developers by sinij · · Score: 1

      Why would you not choose a new method if it is more secure...

      What is being traded in exchange for additional security? It isn't nothing, so don't try that line.

    3. Re:Web developers by WaffleMonster · · Score: 1

      How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?

      I agree FIDO is redundant. It brings nothing useful to the table client certs don't already provide. Any existing UX issues with deployment and management could be addressed instead of attempting to create completely new and redundant standards.

      That said there are few things as deleterious to the continued security of Internet users today than "regular password fields". Continuing to allow insecure authentication as if it's somehow acceptable (Bu....uuu....ttt.. TLS..!!) results in millions falling victim to phishing campaigns that don't need to.

      The fact is that the whole web must change because the whole web is "doing it wrong". Every last site on the Internet with a web login form asking for a password needs to change.

    4. Re:Web developers by Anonymous Coward · · Score: 0

      My understanding is that the new system is "challenge-response," and thus it requires the web sites to change to issue the challenge.

      The challenge is simply a long random number, the response is the digital signature of user on that number. If you have registered a public key with the site, they can then check that the signature is valid, and the response is now worthless to anyone that intercepts it without actively MITMing the exact transaction that caused the challenge-response.

      The hard part is having the server and the client agree on a challenge-response protocol, the server issuing truly random challenges, and the client protecting the "responder" properly to keep the private key private. Other than that, it is basically just a better password system. Additionally, since it is supplemental, you aren't loosing anything.

    5. Re:Web developers by tepples · · Score: 1

      It's not just a user experience difference. Devices implementing FIDO spec also tend to be more hardened against copying out the private key than a browser's certificate store is. I guess this is part of why browser developers have spent more time on FIDO than on TLS client cert UX.

    6. Re: Web developers by OneOfMany07 · · Score: 1

      Yeah because I like typing passwords!

      I mean I assume that's your point as you have no issue to point at (nothing is being lost that you know of... Just a fear of change)

    7. Re: Web developers by OneOfMany07 · · Score: 1

      Except the crap user experience of existing cert methods. Have you used them? I've only tried to add root certs using It directions and that didn't even work the first time. And they expire so you get to juggle them manually.

      I assume FIDO2 is a mechanism for automatic certificate agreement and distribution. So yeah... That'd be a big boon over the existing system in my experience as an attempted consumer of said system.

    8. Re:Web developers by AmiMoJo · · Score: 4, Interesting

      That's not how FIDO works. It uses public key crypto, so you secret never leaves the phone. In contrast with a password the secret (i.e. the password) has to be both transmitted to the server and stored in some fashion (hopefully one-way hashed with salt).

      Of course Chrome also supports auto-fill for passwords, which you can use if for some reason you don't understand what FIDO is.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    9. Re:Web developers by Anonymous Coward · · Score: 0

      > since it is supplemental, you aren't loosing anything.

      Adding attack vectors hardly counts as "not losing anything"

    10. Re:Web developers by Anonymous Coward · · Score: 0

      There's a difference in what gets sent out over the internet. With a hardware token, the website never gets your password so that your password can't be sold to criminals when the site gets hacked.

    11. Re:Web developers by Anonymous Coward · · Score: 0

      Tell em to turn off Web-Pages-over-SMTP.

      Phishing problem solved.

    12. Re: Web developers by WaffleMonster · · Score: 1

      Except the crap user experience of existing cert methods. Have you used them? I've only tried to add root certs using It directions and that didn't even work the first time. And they expire so you get to juggle them manually.

      All major browsers/OS have a means of importing pkcs #12 files easily without much effort. As in you save/open the pkcs 12 file and are greeted with a prompt to add it to the user certificate store. It takes seconds.

      I agree this is far from ideal.. the interaction should be more user friendly/seamless/automated yet it's still very much a trivial process.

      As far as generating certs and expiration policy that's all on the application server. The system we use handles this seamlessly for us while onboarding new users. I can see how people who use third party certificate enrollment tools or CLI scripts to manage this could come away thinking that this is too hard/sucks. It doesn't have to be this way... it's within the application servers ability to control.

      I assume FIDO2 is a mechanism for automatic certificate agreement and distribution. So yeah... That'd be a big boon over the existing system in my experience as an attempted consumer of said system.

      All the same shit (PKI) and all of the same issues. You can more or less "automatically" establish trust with either one but the resulting trust relationship will very much reflect lack of initial input effort.

    13. Re: Web developers by Anonymous Coward · · Score: 0

      Very real things are being lost. I am more comfortable having KeePass2 manage my passwords than Android (since I synchronize with my desktop using a third-party file synchronization program), and that's completely incompatible with FIDO. At the same time, I can definitely see the benefits of FIDO. The correct answer is to support both.

    14. Re:Web developers by dissy · · Score: 1

      How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?

      Uhh, you mean to say you are currently *TYPING* your 8k binary private keys into password boxes on websites?!?

      Dude, you are doing this horrendously wrong! Your private keys should NEVER leave your possession!
      Stop sending them in web form fields, and you should have all of them revoked and make new ones to use properly.

      You never send your private key, you receive a random challenge that you decrypt with your private key and send THAT back.

      I strongly advise against typing all of that binary data as well, but I guess that's up to you.

    15. Re:Web developers by Zmobie · · Score: 4, Informative

      It kind of is nothing actually. At least to the service, some of this depends on how sketchy Google or whomever implements the client side portion wants it to be I suppose. The user still only has to input their secret one time and the service and client systems handle the rest. The main difference is the user now handles their own secret information and doesn't have to trust the service with it. I read up on the standard and this is how it works:

      User creates a local registration public/private key pair with whatever secret they want to use to restrict access on the client side. Then transmit ONLY the public key to the service which then associates this public key with a unique user ID on their system which is then sent to the client for storage and retrieval.

      When the user wishes to login to the service they go to the publicly known location of said service which at 'login' sends their client a challenge first. The challenge consists of the user's unique ID and some type of one-time use question or internal payload that the client has to be able to read in order to answer. The challenge is encrypted by the service using the stored public key and then transmitted to the client to start the process.

      Once the client receives the challenge, it uses the known service association to locate the expected key/value pair association and decrypt that information with the private key that only the local device has access to with the user's permission/interaction (scan your fingerprint, hit your smart card button, etc.). The client system can then validate the internal payload contains the expected unique ID (validating the service is who they say they are) and answer/sign the challenge since it can now be read. Using the internal ID or some other mechanism (some type of session key for a modified diffie-helman I think) the client then encrypts the challenge response and returns it to the service for verification.

      At that point the service validates the payload matches what the client response to what it should be and authentication is complete.

      There are two attack vectors I see and neither are easy to do at scale. One, compromise the registration such that when the service sets up the user with their Unique ID that was created on the service side the user associates it to the attacker's unique ID instead. An attacker could then impersonate the service and attempt to harvest information that way. It wouldn't enable a full MITM attack still simply because without access to the private key there is no way for the attacker to impersonate the client and authenticate properly with the service.

      The second, obviously, is breaching the local device. As I have pointed out in a couple other posts though, attackers have to breach every device individually now though creating scaling issues. Not only that, if the authentication methods used are separated per service, it only gets the attacker access to the private key of that single service assuming they don't have persistent access and can wait for the user to use all secrets over time (essentially individual encryption on the keys themselves makes this even more difficult with minimal user interaction required still, but unlikely many users would do this without having very high security needs). Separating devices that store the private keys would also create at least segmented security as well such that the user would not lose everything if one device is persistently breached.

      Generally I like the standard. I may not have everything correct, and I think some of my understanding may actually be assumed internals. If anyone has any corrections or sees issues, feel free to chime in. The service would still be able to uniquely fingerprint an individual for tracking purposes, but I don't see a way around that for single user authentication anyway. Kind of difficult to let a user be anonymous when they have a unique account on the service anyway...

    16. Re: Web developers by Anonymous Coward · · Score: 0

      Are FIDO credentials just magically synced via your Google account. Or are they stuck on your phone? I didn't see this listed on FIDO's website.

    17. Re:Web developers by Anonymous Coward · · Score: 0

      If Google lets customers login with this then it’s newsworthy. If google won’t and wants other ppl to use it then this is spam.

    18. Re:Web developers by thegarbz · · Score: 1

      for your new special feature

      FIDO2 is not special, and given Webauthn is 3 years old it's hardly new at this point either.

      How about you design your FIDO2 thing to automatically type passwords into regular password fields

      How about we don't gimp new protocols by reverting their security to the lowest common denominator, a denominator which has been repeatedly shown to be wildly insecure and susceptible to all manner of attacks to say nothing of rampant end user misuse.

    19. Re: Web developers by Zmobie · · Score: 1

      Knowing Google, they will offer a magic sync through the Google account. However, their standard is supposed to be device agnostic from what I understand. I think you are supposed to be able to transfer it through some type of data import/export mechanism typically, but I'm sure the details of that would be handled by the company implementing the standard in their own application(s).

  5. They are called client certs by WaffleMonster · · Score: 1

    A technology that has been supported by all major browsers since the beginning of time itself.

    1. Re:They are called client certs by The-Ixian · · Score: 1

      That seems to be a pretty cumbersome system for users as they would have to either pay to be recognized by a CA and/or would have to go through a rigamarole set-up procedure to install a certificate in every piece of Internet-communicating software they use.

      Also, what happens if that cert gets lost? Now they have to revoke it (and we all know what a joke the cert revocation system is) and go through the whole thing again...

      --
      My eyes reflect the stars and a smile lights up my face.
    2. Re:They are called client certs by flink · · Score: 1

      A technology that has been supported by all major browsers since the beginning of time itself.

      I've dealt with client certs quite a bit having been a government contractor both utilizing and writing software which does CAC/PIV (i.e. client certificate) authentication. While it is an effective way to secure an endpoint, the user experience is less than ideal. Because the client cert is negotiated as part of of the TLS handshake, when it fails it is difficult to give any meaningful feedback to the user. They usually end up just seeing an SSL error or a 401 HTTP server response. The UI browsers present to chose a certificate is rather rudimentary and for good reason not under the control of the application developer. In addition, most browsers pin the client certificate choice for the duration of the session, so if a user accidentally chooses the wrong certificate, they have to quit out and restart their browsers.

      All of this is not to mention the logistical hassle of issuing certificates, maintaining a CRL, getting smart cards out to people, etc. This and the usability issues are tractable for a large organization whose users will receive training on how to deal with mutual authentication, but for the general public I think it would be kind of a non-starter.

    3. Re:They are called client certs by WaffleMonster · · Score: 1

      I've dealt with client certs quite a bit having been a government contractor both utilizing and writing software which does CAC/PIV (i.e. client certificate) authentication. While it is an effective way to secure an endpoint, the user experience is less than ideal. Because the client cert is negotiated as part of of the TLS handshake, when it fails it is difficult to give any meaningful feedback to the user.

      Most secure authentication systems only provide pass/fail feedback by design.

      Here you at least have a choice. You can setup the web site to not require certificate authentication so that if authentication fails the user is given instruction on what they can do/contact to get the issue resolved.

      The UI browsers present to chose a certificate is rather rudimentary and for good reason not under the control of the application developer. In addition, most browsers pin the client certificate choice for the duration of the session, so if a user accidentally chooses the wrong certificate, they have to quit out and restart their browsers.

      I completely agree the client implementation sucks in many regards but these are implementation problems that can be resolved with relatively minor effort. This isn't an excuse to reinvent the wheel.

      All of this is not to mention the logistical hassle of issuing certificates, maintaining a CRL, getting smart cards out to people, etc. This and the usability issues are tractable for a large organization whose users will receive training on how to deal with mutual authentication, but for the general public I think it would be kind of a non-starter.

      The issues are exactly the same regardless of key based possession system you use. It's always a series of tradeoffs between ease of use and security.

      You could easily automate issuing certs on first logon for normal users. CRLs can be avoided by having application server keep a list of acceptable ID's.

      When it comes to public sites small UX tweaks to close the loop on initial signup/first login would provide security benefits.

      In many ways 2FA is, was and always will be a non-starter for public. The public push isn't driven by security as much as it's driven by a desire for companies to minimize dealing with the headaches associated with "I forgot my password".

      Client certs can be deployed in ways that makes them every bit as feckless as most public facing 2FA systems with minimal effort/change.

    4. Re:They are called client certs by WaffleMonster · · Score: 1

      That seems to be a pretty cumbersome system for users as they would have to either pay to be recognized by a CA and/or would have to go through a rigamarole set-up procedure to install a certificate in every piece of Internet-communicating software they use.

      It's not like this. The best high level explanation I can give is that client certs are like browsing to a secure site except in reverse.

      When you go to https://www.reallysecuresite.o...

      1. Your browser has a listed of trusted certs handed down by the CA gods.
      2. www.reallysecuresite.omg has a private/public key pair blessed by CA gods.

      Client certs flip this.

      1. With client authentication the browser has private/public key pair blessed by www.reallysecuresite.omg.

      2. www.reallysecuresite.omg has a list of trusted root certs blessed by itself.

      You don't need the blessing of third party to hand out client certs. It costs you nothing and there is no disadvantage to it.

      Also, what happens if that cert gets lost? Now they have to revoke it (and we all know what a joke the cert revocation system is) and go through the whole thing again...

      If the client looses it's private key to authenticate to www.reallysecuresite.omg it has to petition the site for a new one if a backup is unavailable.

      It's the same thing if you lose your smart card or USB yubikey. Perhaps the site allows you to login with your username and password and have a new key automatically issued to you. This obviously isn't secure but most public facing sites do garbage like this all the time because they don't care about security. They care about ease of use and not dealing with password reset and market it as a security improvement.

      If the server loses its private key then it only loses the ability to issue new certificates to users without creating a new CA which is free. It continues to have the ability to authenticate existing users. A reasonable price given the scenario.

  6. What's wrong with keepass? by Excelcia · · Score: 2

    They want me to trust an Android phone to authenticate all my logins? Are they high?

    Switch to KeePass and family. Create a database with a keyfile and a master password. Distribute the database using I switched to KeePass and family a couple years ago, and it was the best thing I ever did. Use a master-password plus a sneaker-net distributed keyfile to protect the database. You can share the database with something like SyncThing, that has end-to-end encryption you control just for added safety but really you could share the database publicly with complete safety at that point.

    Don't get me wrong, I like Android. But Google has been in the NSA's back pocket from the beginning. Not that Assange is one of my favourite people, but he did make a compelling case for Google being essentially an arm of the US government. Which is one reason why China had it out with them (we may get on Huawei's case for back-doors, but we did it to them first with Google and Windows).

    1. Re:What's wrong with keepass? by Anonymous Coward · · Score: 0

      KeePass is not a solution. Suppose that you're logged into your bank on your phone, and someone runs away with your phone and attempts to transfer your balance. At this point your bank asks for your password to confirm the transaction, but KeePass jumps in and ruins the defensive measure by filling in your password.

    2. Re:What's wrong with keepass? by The-Ixian · · Score: 1

      Nothing wrong with KeePass and ilk, it is just perpetuating an outdated model.

      There are better ways to authenticate these days.

      I get that you are technologically adept, but not everyone is. Those who are not are still valuable humans just like you.

      For those who fear the three letter agencies (as you should), there will (hopefully) always be alternatives. For the masses, there will be a trade-off made where some level of spying, in the name of safety, will be implicit.

      We make the same trade-offs in the "offline" world. The gov'mint has the ability to force you to open your wall safe. The same will almost certainly be proved reasonable for phones and encrypted communications eventually. As unreasonable as you may think that is personally, society as a whole has/will make that choice and you are benefiting from living in society so.... I guess deal with it.

      As long as we have awareness (watchdogs) and open alternatives, I think we are fine.

      --
      My eyes reflect the stars and a smile lights up my face.
    3. Re:What's wrong with keepass? by b0s0z0ku · · Score: 2

      The problem is that the US is extremely authoritarian while marketing itself as free. The watchdogs are powerless over the wails of cops and cowards that "if you have nothing to hiiiiiiiide, why do you need priiiiiiivacy?"

    4. Re:What's wrong with keepass? by DarkRookie2 · · Score: 1

      Why IN THE FUCK, are you banking on your phone.
      Much less with the banks app.

      --
      http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
    5. Re:What's wrong with keepass? by DarkRookie2 · · Score: 1

      I get that you are technologically adept, but not everyone is. Those who are not are still valuable humans just like you.

      This isn't an excuse. Computer have been around since the early 70s. Either learn or don't use any device. Your dumbass fault for using the same shitty password on all your sites cause you refuse to learn.

      --
      http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
    6. Re:What's wrong with keepass? by thegarbz · · Score: 1

      What's wrong with Keepass? You mean other than having to send your credentials across the internet? Also if you don't trust your Android device then you can't trust running Keepass on it and you've already lost.

    7. Re:What's wrong with keepass? by thegarbz · · Score: 1

      Because he's a normal person safe in the knowledge that unless his phone is entirely made of fake Chinese PlayStore copycats that distribute only malware he is actually safer using his phone's custom app than transmitting a banking password on a complex PC using a standard browser?

  7. Spoofing by Anonymous Coward · · Score: 0

    Because spoofing

    But the whole dongle thing is a stupid idea for other reasons anyway

    1. Re:Spoofing by DarkRookie2 · · Score: 1

      Especially since they are around $50 and not free.

      --
      http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
  8. Websites wlil probably continue to require SMS by tepples · · Score: 1

    I didn't read the article because WIRED happens not to be part of my current subscription package. But based only on the quoted paragraph, I see two practical problems likely to arise.

    The first is the requirement of "Android 7 or later". that last I checked, phones were still being sold multiple major versions of Android behind because newer versions of Android require more CPU and RAM than fit in the bill of material for a budget prepaid smartphone. Which entry-level phone ships with 64-bit Android 7 or later?

    The second is that some major websites won't let the user set up 2-factor authentication through U2F or TOTP without first setting up 2-factor authentication through SMS. One example is Twitter, which 1. requires the user to set up SMS before setting up TOTP, 2. sends SMS on every login attempt even after TOTP has been set up, and 3. removes TOTP if the user removes SMS.

    A requirement of SMS before U2F or TOTP causes problems in three situations I can think of. The first is people managing business accounts who may not have a cell phone at all at the office, instead relying on the office landline. The second is people on a pay-as-you-go plan, particularly in the United States where PAYG carriers charge for each incoming voice minute or SMS message. The third is people who know SMS isn't a reliable third factor because of the documented cases where a social engineer convinced the carrier to transmit some other subscriber's service to a new SIM without the subscriber's authorization, and then preceded to use that SIM to unlock the victim's email and other accounts.

    1. Re:Websites wlil probably continue to require SMS by b0s0z0ku · · Score: 1

      The fourth problem is that not everyone wants to tie their usage of Web services to a phone number (aka a real-world identity). Requiring a phone number to create an account is a loss of privacy.

    2. Re:Websites wlil probably continue to require SMS by Anonymous Coward · · Score: 0

      Just since you asked... my Moto G4 Play (which I purchased retail for $150 in late 2016) was upgraded to 7.1.1 on nearly its last official OTA update before being abandoned by Moto.

      I completely agree with your two-factor SMS rant. I am still aggravated by my inability to control my own retirement account security. They are now forcing me to "upgrade for my protection" and in the process will require me to enroll my phone number. As best I can tell, this will enable an account-recovery mechanism via SMS which means they took my strong password, "upgraded" it with 2-factor, then handicapped it with easily hacked SMS which works as 1-factor recovery to make sure anybody can hijack me easily.

    3. Re:Websites wlil probably continue to require SMS by drinkypoo · · Score: 1

      Which entry-level phone ships with 64-bit Android 7 or later?

      Moto X4, available at $140 or less carrier locked (I paid $150 for the unlocked Android One version) supports Android 9. It also has ARCore support. I tried and tried to find something better and/or cheaper with water resistance (X4 claims full IP68) and failed. Granted, it's at about the end of its lifecycle, so updates will probably stop soon, but since it's actually current now that should hold me for a while. I'm replacing a Moto G2, on which I am currently running Pixel Experience, so I'm going to double my cores and triple my RAM. The X4 doesn't have a battery door, but it does have a headphone jack.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  9. One Year Later... by Zorro · · Score: 1

    200 Million Biometric credentials stolen in Security breach.

    It is inevitable.

  10. Android is helping to spread pervasive tracking by sinij · · Score: 4, Insightful

    Corrected headline - Android is helping to spread pervasive tracking.

    User name and password is "something you know", and as such is not something that can be used without your explicit consent. Seamless login is "something you have", and since it is part of your phone, it doesn't require your explicit consent to be checked.

    Make no mistake, this is about removing what little anonymity is left from the Internet. FIDO standard is effectively a Real Name Only policy disguised as progress.

    1. Re:Android is helping to spread pervasive tracking by b0s0z0ku · · Score: 2

      Yep, nailed it -- this is about techscum like Google wanting to hold the keys to the safe.

    2. Re:Android is helping to spread pervasive tracking by surd1618 · · Score: 2

      When I can't use an Android device without signing in to Google, I will not buy another Android device.

    3. Re:Android is helping to spread pervasive tracking by Oswald+McWeany · · Score: 3, Interesting

      Corrected headline - Android is helping to spread pervasive tracking.

      User name and password is "something you know", and as such is not something that can be used without your explicit consent. Seamless login is "something you have", and since it is part of your phone, it doesn't require your explicit consent to be checked.

      Yes, and I use a dozen different e-mail accounts to make it slightly harder for different companies on the web to know that I am the same person if they try and share data. I don't want the same account ID on every site I go to.

      I want Amazon and Slashdot, for example, to not know I'm the same person if they share databases. Or my bank and Google, etc. I know there are other ways of tracking and I'm probably not fooling the big guys much- but I want to log in different places as "different people".

      --
      "That's the way to do it" - Punch
    4. Re:Android is helping to spread pervasive tracking by AmiMoJo · · Score: 1

      Wrong. The browser does require you to explicitly consent to seamless login credentials. There is an on-screen prompt every time, unless you explicitly tick the "don't ask again for this site" box.

      This is a big win for most people. It can be used in addition to a username and password, or with just a username, if desired.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:Android is helping to spread pervasive tracking by tepples · · Score: 1

      Seamless login is "something you have", and since it is part of your phone, it doesn't require your explicit consent to be checked.

      Unless unlocking the phone's FIDO keystore requires your fingerprint (Touch ID) or a direct stare (Face ID) or your hand veins (Hand ID) or at least some other expression of consent. Does it?

    6. Re:Android is helping to spread pervasive tracking by AmiMoJo · · Score: 1

      Here's the standard, as you can see it requires user interaction before authentication can take place:

      https://fidoalliance.org/specs...

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Android is helping to spread pervasive tracking by 93+Escort+Wagon · · Score: 1

      Corrected headline - Android is helping to spread pervasive tracking.

      I am shocked. SHOCKED! Are you saying an advertising company has an economic incentive for the continued development of Android?

      --
      #DeleteChrome
    8. Re:Android is helping to spread pervasive tracking by Anonymous Coward · · Score: 1

      You already can't download anything from Google Play without signing in, though. Are you able to find enough software from other sources?

    9. Re:Android is helping to spread pervasive tracking by swillden · · Score: 2

      Corrected headline - Android is helping to spread pervasive tracking.

      You don't know what you're talking about. The FIDO2 approach to online auth uses a different key to authenticate to every we site and is designed to make it impossible to connect a login to one site with a login to another site (unless user-provided data provides a connection between them).

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:Android is helping to spread pervasive tracking by Zmobie · · Score: 1

      I think it does from what I was reading. It may have the option to do it without the interaction, but it looks like it is setup such that the user needs to consent to unlocking the private key for that service.

    11. Re:Android is helping to spread pervasive tracking by Anonymous Coward · · Score: 0

      Most existing hardware tokens will not store that many different private keys. Are there any that do?

      I understand that FIDO2 will work fine without that, but having a hardware key and not storing the actual keys on it is idiocy.

    12. Re:Android is helping to spread pervasive tracking by thegarbz · · Score: 1

      FIDO standard is effectively a Real Name Only policy disguised as progress.

      With the exception of FIDO not being anymore tied to my Real Name than my Slashdot pseudonym is. Sure. A bit less of the tinfoil hattery and a bit more understanding how public key cryptography works please. You're on a tech forum. Act like it.

    13. Re:Android is helping to spread pervasive tracking by ffkom · · Score: 1

      While suspicion is always a good thing, FIDO is less inclined to expose your identity to some arbitrary web service than classic TLS client certificates or simple cookies or JavaScript run-time environments are.

      The FIDO standard itself is definitely not guilty of trying to increase tracking capabilities.

      But of course, a malicious implementation of FIDO in a browser could be abused by the browser's vendor to facilitate even more tracking. So a non-Google open source browser implementing FIDO would certainly be even better.

    14. Re:Android is helping to spread pervasive tracking by surd1618 · · Score: 1

      Aurora store just quit working I think so it's f-droid and direct downloads at this point.

    15. Re:Android is helping to spread pervasive tracking by surd1618 · · Score: 1

      Actually take that back, you can create a random google account and then sign into it with aurora store without signing in the whole phone. The anonymous aurora store account just quit working recently so I just checked and figured this out.

    16. Re:Android is helping to spread pervasive tracking by WaffleMonster · · Score: 1

      While suspicion is always a good thing, FIDO is less inclined to expose your identity to some arbitrary web service than classic TLS client certificates or simple cookies or JavaScript run-time environments are.

      Why less? FIDO can be configured to prompt. TLS authentication can be configured likewise to prompt. FIDO has channel bindings allowing servers to get indications of usage at transport level same as TLS.

      What specifically makes FIDO *less* inclined?

    17. Re:Android is helping to spread pervasive tracking by jouassou · · Score: 1

      I use a Google-free version of Android on my phone. I try to use F-droid apps where I can. When that is not sufficient, I often check if there's a webapp for it. Webapps can't run in the background, and can't force arbitrary permissions out of you, so they at least track you less than ususal apps. So e.g. the few times I need to resort to Google Maps, having a bookmark to the web page that opens in a mobile browser is sufficient. When I really need a proprietary app, I use Amazon's app store (doesn't need as many permissions as Google Play Services) or Yalp (downloads free Google Play apps without a Google account).

    18. Re:Android is helping to spread pervasive tracking by SirCowMan · · Score: 1

      YALP works, it's on F-Droid.

      In order to really work without Google though, one needs also to replace play services, location services, cloud messaging (GCM/firebase), disable the hotspot checking, disable safetynet checks, etc., it's more than just not signing in - there are a pervasive number of googley tie-ins.

      Need root + firewall + something like MicroG and a healthy dose of paranoia to seperate Google and Android.

      --
      !Equality through palindromes semordnilap hguorht ytilauqE!
  11. No thanks by Anonymous Coward · · Score: 0

    I don't trust anything that rogers has its hand in. FIDO has a terrible history in mobile and I doubt that FIDO2 will be any different. The existence of a FIDO Alliance screams collusion.

  12. Great progress. by 140Mandak262Jamuna · · Score: 1

    Earlier hackers needed to crack one site at a time. Now, thanks to innovation and advances, all they have to do is to crack android.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:Great progress. by sinij · · Score: 1

      ... all they have to do is to crack android.

      Or they could just wait few months for a metasploit module to come out targeting carrier-locked Android phones that are at least a decade behind on patching.

    2. Re:Great progress. by Anonymous Coward · · Score: 0

      No need to crack Android - there are plenty of malicious Apps already doing that, willfully installed by the clueless with lots of gullible friends on Facebook, which were "thoroughly vetted" by the Google Play Store scanner.

    3. Re: Great progress. by OneOfMany07 · · Score: 1

      Wonder if we'll ever find a way to get long term support? I'm hoping Google's project "treble", I think it was called, will help. Think it was a tweak to the kernel that allowed plug and play kernel updates, versus the current custom compiled in drivers.

      Maybe we need to make sure those "right to repair" legislations people are working on includes software, not just hardware. From the few details I'd read I thought one did (Massachusett?) but I really should investigate them better.

    4. Re:Great progress. by Zmobie · · Score: 1

      I mean, that was already the case though? Same with Windows really. The attack surface of breaching user devices to steal secret information isn't miraculously materializing from this standard, it was already there. If one's phone were compromised then the keylogger on it is already stealing all your credentials and what site they go to.

      At least with this type of standard the user device HAS to be hit in order for the private key to be compromised. This actually decreases the attack surface and makes remote exploitation more difficult since now breaching the site doesn't actually get you full access to user credentials. Not only that, it would at least allow for a larger portion of the security levels and status to be determined by the user rather than a service just forcing them on their users with varying levels of success/caring.

      Hell with some additions to the standard you could actually restrict data access on the server to a private key held on a local device that is given only while the data needs to be accessed. The user would have to trust the service to discard the key after actions have completed, but the user's now are having to trust the service to safeguard their data. Some services would never do it either simply because then they can't access the user's data for harvesting, but if a service wanted to offer really high security this is a possibility. It would render stealing databases effectively useless for attackers because there is no way they would be able to break every single encryption key for every user.

    5. Re:Great progress. by ffkom · · Score: 1

      Why crack Android when it is just the colorful bloat-ware browser that you need to crack, in order to access every interaction of the user with some web service? FIDO or not FIDO does not make a difference to this kind of threat. After the death of Flash, JavaScript is certainly the biggest contributor to this threat.

  13. I like my passwords... by b0s0z0ku · · Score: 4, Insightful

    I don't want to be dependent on a given device or ecosystem for using a website or an app, and I don't necessarily want to tie it to my identity via biometrics. I can make passwords arbitrarily complex, yet easy to remember, and even write them down in a little book (kind of hard to hack remotely).

    Password-less authentication isn't about security -- it's about control and LACK of security. Google wants to hold the keys to the city.

    1. Re:I like my passwords... by swillden · · Score: 1

      Password-less authentication isn't about security -- it's about control and LACK of security. Google wants to hold the keys to the city.

      Nope. Google has no access to any of the keys used.

      Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

      What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:I like my passwords... by WaffleMonster · · Score: 2

      Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

      What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

      This is a scary argument.

      Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.

      You are right in that this is not because they are the root CA "for much of the" web.

      It's much more basic than that. It's simply because they are a CA and therefore inherently in a position to globally issue certs trusted unconditionally by all clients using the web regardless of how many customers an individual CA has.

      If Google is able to do something similar WRT to authentication then it's to borrow a phrase from Joe Biden ... a big fucking deal. I would hope that Google DOES NOT have the ABILITY to bypass FIDO authenticated identity seen by applications relying on this system for authentication. If it is possible for Google to issue itself a key pair to impersonate one of my users then in fact the system is inherently broken, unfit for purpose and should not be used by anyone.

    3. Re:I like my passwords... by swillden · · Score: 2

      Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

      What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

      This is a scary argument.

      Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.

      Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair and the site you're authenticating to stores the public key. The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware -- and only if they care to verify that (in most cases, I can't think they'll even bother.).

      Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.

      BTW, to be clear, I should say "we", not "they". I'm the lead engineer for and designer of the Android Keystore attestation that is the root of trust for Android WebAuthN. If you have any questions about how keys are generated, managed, revoked, etc., just ask.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:I like my passwords... by Zmobie · · Score: 1

      I imagine one of the mechanisms for FIDO authentications retrieval of a private key is actually entering a password. The difference is the password never leaves the device nor does the private key itself. This is also a standard not necessarily a specific device/ecosystem/vendor/ etc. which we are already extremely dependent on thousands of standards to do anything with technology.

    5. Re:I like my passwords... by Zmobie · · Score: 1

      You do bring up a solid point that them being able to issue root certificates is a significant problem if abused, but I don't think they can impersonate a user that has registered to the service with their own keys. The certificate is merely to certify they are who they say they are for whatever purpose.

      The problem is that since the FIDO challenge contains a challenge question that must be answered to authenticate (and it is encrypted and can only be decrypted using the user's private key), even a root CA can't answer it without the user's private key. They could impersonate that they are the ones that are supposed to be receiving the challenge without issue, but they would be unable to answer the challenge because they can't read it. Now this assumes the implementation does not key off of the certificate itself, but everything I read says the user has control of whatever secret they want to use to lock their key(s).

      Technically, if I understand how the standard is intended to be used, this actually solves some of the CA abuse cases simply because without access to the user's secret no one can actually impersonate them. Whereas under the current system a CA could easily spoof the login page of popular services, issue a valid certificate and harvest all those secrets as people trust them. Under the FIDO standard they can't obtain the secret, the private key for the service, or much of anything beyond possibly the unique service ID for a user.

    6. Re:I like my passwords... by WaffleMonster · · Score: 1

      Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair.

      Of course this in itself doesn't mean anything. Creation of a key pair doesn't preclude existence of parallel trust paths.

      and the site you're authenticating to stores the public key.

      When I login to a site using this system are you saying the sites keep a database of actual public keys and validates by matching my individual public key from that databases? It doesn't simply perform validation using something more manageable higher up trust chain?

      The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware

      I don't understand how this is possible. Does each piece of hardware have a factory installed key pair to establish this? What is the basis for determining security of key storage?

      Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.

      What is the benefit of Google's CA in the first place? What functionality is enabled that wouldn't be possible without it? Is it just this idea of proving the security of key storage and nothing else? What breaks without it?

    7. Re:I like my passwords... by thegarbz · · Score: 1

      I don't want to be dependent on a given device or ecosystem for using a website or an app

      It's not. There's always a fallback.

      and I don't necessarily want to tie it to my identity via biometrics.

      It's not. That's not how fingerprint authentication works on any device with any standard.

      and even write them down in a little book (kind of hard to hack remotely).

      Please do us a favour and don't ever talk publicly in an article about security again.

  14. Biometrics A Slippery Slope by BrendaEM · · Score: 2

    First it was fingerprints, then it was the face. While the question where it will end exists, does anyone notice that they are just scanner our bodies part by part, and selling the information?

    --
    https://www.youtube.com/c/BrendaEM
    1. Re:Biometrics A Slippery Slope by sinij · · Score: 2

      Error. Post aborted. Failed to confirm user identity. Please firmly re-insert authentication device into your sphincter and try posting again.

    2. Re:Biometrics A Slippery Slope by Anonymous Coward · · Score: 0

      Your bodies perhaps. I've never used biometrics to protect anything.

  15. No mention of SQRL Login by MCRocker · · Score: 3, Interesting

    I'm a little shocked to see an article on FIDO without even a mention of Steve Gibson's competing Secure Quick Reliable Login.

    Although I'm not an expert on this, most reports I've heard is that SQRL, is what FIDO was trying to be.

    One key feature of SQRL is that it only does one of Authentication and Authorization, so it can be used for anonymous login, which would be better for many purposes, such as blog comments where you only need to verify that some response belonged to the same author as some other so nobody could impersonate someone else. Though it looks like FIDO may also do this.

    --
    Signatures are a waste of bandwi (buffering...)
    1. Re:No mention of SQRL Login by tepples · · Score: 1

      SQRL [...] can be used for anonymous login, which would be better for many purposes, such as blog comments where you only need to verify that some response belonged to the same author as some other so nobody could impersonate someone else.

      So can client certificates in a web browser, if only their UX weren't so horrible. So can a "tripcode", or a self-assigned password whose hash salted by the email address is displayed publicly, as 4chan has demonstrated.

    2. Re:No mention of SQRL Login by bill_mcgonigle · · Score: 1

      Those fail the requirements of not needing a CA and not needing separate keys from separate websites. SQRL gets these right.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  16. Client certs are a UX nightmare by tepples · · Score: 4, Insightful

    One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key. This lets a U2F key pass more tests for being "something you have."

    The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."

    • No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.
    • Backing up certificates and moving them among devices isn't easy.
    • Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site

    Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways:

    • When a TLS site requests a client certificate, show a key icon in the location bar next to the TLS lock icon. This opens the certificate chooser. The user can click it again to log out.
    • Group certificates in the certificate chooser by the registrable domain* with which they were last used.
    • Let the user drag certificate files in and out of the certificate chooser.
    • Include client certificates in the browser's password sync feature.

    But good luck getting browser publishers to devote any time==money to this.

    *A "registrable domain" is a public suffix, as defined by Mozilla's Public Suffix List, plus one name part. If "co.uk" is a public suffix, for example, then "ebay.co.uk" is registrable.

    1. Re:Client certs are a UX nightmare by WaffleMonster · · Score: 2

      One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key.

      There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.

      The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."

      So instead of addressing usability problems the answer is to create an entirely new incompatible protocol? Fuck that. I use client certs every day and it's no more of a usability nightmare than HTTP authentication.

      No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.

      This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.

      Backing up certificates and moving them among devices isn't easy.

      This is nonsense. All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.

      Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site

      They are not domain based they are signer based. The proper certificate is generally always selected automatically based on who signed it in the first place unless there is a name collision with signer in which case a list of matching client certs are displayed. In no entirely preventable event are users given an infinite list of certs to choose from only the matching list.

      Users on a per domain basis existing browsers can be configured prompt whether or not to use a cert to mitigate usage as tracking mechanism.

      It would also be trivial to add constraints to client certs which limit domain applicability. There is no reason to invent a new standard.

      Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways

      This is commonly used by "enterprise" systems rather than customer facing web sites.

    2. Re:Client certs are a UX nightmare by tepples · · Score: 2

      There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.

      If you're doing the signing on the computer, an attacker can copy the private key on its way from the module to the computer or copy it out of the browser process once it is in the computer. If you're doing the signing on the module, that is exactly what FIDO aims to do. What am I missing?

      This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.

      I notice the sarcasm. It's required in a browser only because as of first quarter 2019, more customer-facing websites support FIDO than TLS client certificates.

      All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.

      The structure of FIDO ensures that the private key never leaves the device, unlike with a TLS client certificate whose key pair must be copied into the TLS stack's address space to be used. As I understand it, this safeguarding of the private key is necessary for the device to be considered a second factor, as "something you have" rather than "something you know", in case someone compromises your password manager.

      They are not domain based they are signer based.

      Who is the signer in common uses of TLS client certificates? In hypothetical use thereof on customer-facing websites, who would be the signer? How does the deprecation of the <keygen> element change this answer?

      This is commonly used by "enterprise" systems rather than customer facing web sites.

      In order to improve the usability of TLS client certificates to the point where customer-facing websites can use them, an overhaul of the user interface is needed. Feel free to contribute a pair of pull requests, one to Firefox and one to Chromium, that does this.

    3. Re:Client certs are a UX nightmare by ffkom · · Score: 1

      FIDO itself does not enforce a client key to reside on any specific hardware, so it could theoretically reside in just some software-implemented key storage.

      But unlike TLS client certificates, FIDO is well-prepared to work for web sites that want to make sure the client is actually using some sort of hardware key storage, from where it is never transferred into the main memory.

      So I understand the most prominent advantage for e.g. a bank would be that they could issue their favorite hardware token to the user and be pretty sure that as long as a FIDO supporting browser is available to the user, he will also be able to use the hardware token for "online banking" without exposing his key to those who compromised his computer. (Which of course does not preclude every possible abuse scenario.)

    4. Re:Client certs are a UX nightmare by WaffleMonster · · Score: 1

      If you're doing the signing on the computer, an attacker can copy the private key on its way from the module to the computer or copy it out of the browser process once it is in the computer. If you're doing the signing on the module, that is exactly what FIDO aims to do. What am I missing?

      There are a number of deployment options. In high security systems keys are loaded onto smart cards and handed off to users. Private keys never leave the card.

      In low security situations where you just want to protect users from phishing key pairs would just be downloaded initially during initial onboarding and loaded into systems user cert store.

      You could also do signing request from the hardware itself. No matter what solution you pick it's all RSA and it's all about managing private keys. The same options can be available no matter what.

      Personally I don't much care about arguments involving local system compromise. My view is successful hijacking of just a single session is game over. I see limited value in distinctions that attempt to "limit damage" to follow on sessions. Game over is game over.

      If the system is compromised during initial key signing when trust is established with FIDO you're also screwed no matter where private key is stored. An attacker could simply submit their own signing request using their private key and MITM proxy a parallel handshake to make you think it worked when in fact the attacker registered as you not yourself. It's still all bets are off when local system is compromised.

      I notice the sarcasm. It's required in a browser only because as of first quarter 2019, more customer-facing websites support FIDO than TLS client certificates.

      As a site owner client certs are currently by far more universally supported with lower barrier to entry for security conscious users.

      The structure of FIDO ensures that the private key never leaves the device, unlike with a TLS client certificate whose key pair must be copied into the TLS stack's address space to be used.

      This is not true. With client certs RSA operations can occur within the smart card or security module. Private key need never leave the hardware.

      Who is the signer in common uses of TLS client certificates?

      The site owner who has created their own CA to issue certs to their users.

      In hypothetical use thereof on customer-facing websites, who would be the signer?

      The site owner runs the CA and is the signer. If my company is called "Waffle's Widgets" when my user goes to one of my sites a certificate for Waffle's Widgets is loaded. If there is another company out there using the same name and the user happens to have an account on both they are prompted to select which cert they want to use. Picking the wrong one results in message authentication failure. Picking the right one results in successful sign-in. This issue is a nothing burger.

      How does the deprecation of the keygen element change this answer?

      My personal view is that keygen is pointless.

      In order to improve the usability of TLS client certificates to the point where customer-facing websites can use them, an overhaul of the user interface is needed. Feel free to contribute a pair of pull requests, one to Firefox and one to Chromium, that does this.

      Firefox user experience is really not that bad in this regard. If site pushes a pkcs file it comes right up and asks you to install cert which is just fine during signup/onboarding process.

      I'm a million times more interested in getting existing TLS-SRP patches enabling secure mutual username / password authentication committed into the major browsers. This is much more important to me as in my view stands the best chance to meaningfully increase system security and mitigate phishing.

      I see public facing 2FA as a marketing pl

    5. Re:Client certs are a UX nightmare by WaffleMonster · · Score: 1

      But unlike TLS client certificates, FIDO is well-prepared to work for web sites that want to make sure the client is actually using some sort of hardware key storage, from where it is never transferred into the main memory.

      This idea that private key operations of client certs have to be handled in software requiring keys to be transferred to the host system is simply not correct.

      Smart cards have enabled exactly this for at least a dozen years and counting. They also happen to cost four times less than current USB sticks.

  17. No way in hell by Harry_Bawls · · Score: 0

    I don't mind typing my password if it keeps my info safe. To me, this just seems like another way to separate stupid people from their money.

    1. Re:No way in hell by Zmobie · · Score: 1

      I'm not sure what you mean? FIDO is a standard, they aren't actually selling anything. It also actually removes some of a user's information from being under the control/protection of the online services...

  18. Re: Android is helping to spread pervasive trackin by OneOfMany07 · · Score: 1

    This (no requirement to always automatically trigger any system but for safety). If users want it then go build it and sell it or give it away.

    The only time the government should block that is if they're like China ("dissention is evil"). Otherwise we should be able to call them out and build a system to fight it.

    Otherwise it's just a monetary issue. Said company won't let you so go reimplement or figure out a public health reason to have the government regulate them into submission. If they won't then shame the government for said collusion.

  19. Awesome by Anonymous Coward · · Score: 0

    Now armed robbery can include amputations of digits for use as ATM card. Thanks Google.

  20. Device security by ironicsky · · Score: 2

    If only they would apply 2FA policies to device authentication. Using their BLE token , you should not be able to unlock your device without your token and a finger print or password.

    As others have mentioned, finger prints can be faked, passwords can be guessed, but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.

    Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.

    1. Re:Device security by swillden · · Score: 1

      Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.

      Be sure to use a short screen lock timeout, set your device to lock when the power button is pressed, and make a habit of always pressing it when you are done using your phone. Basically, maximize the odds that if your device is lost or stolen, it will be in a locked state.

      As others have mentioned, finger prints can be faked, passwords can be guessed

      Fingerprints can be faked, and I don't have any recommendations as to how to mitigate that risk. You could choose not to use biometric authentication, but in most cases I think that's a bad tradeoff, since the convenience of fingerprint auth makes it practical to lock your phone much more aggressively. So, using fingerprint auth increases your risk against attackers who are willing to go to the effort of lifting prints and making gummi fingers, but increases the odds that lazy attackers will find that your phone is locked against them. I think for most people the tradeoffs fall on the side of aggressive locking and use of fingerprint auth.

      Passwords (including PIN and pattern) are harder to guess than you might realize. Android has mandated that password matching happen in secure hardware that enforces guess rate limiting since Nougat. I think the mandated rate limiting is a too permissive, but it's enough that without some clues even guessing a four-digit PIN would take months, if not years. If the attacker is that dedicated and focused, odds are that your phone isn't the path of least resistance.

      but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.

      Interesting idea. I haven't heard of any demand for phone login 2FA, but it could be a good idea.

      (Note that what follows is me thinking out loud; sorry that it's kind of rambling.)

      I'm not sure if a BLE token is the right tool, but it might be. I'll look into it (I'm the lead engineer and manager for some of the relevant bits of Android). I think we'd need backup options in case the token were lost or stolen. Maybe on devices with a biometric authenticator, you could unlock with {password|fingerprint} + token, or if you didn't have your token you could unlock with password + fingerprint, so 2FA that way. Or password + fingerprint + face, if devices with both face auth and fingerprint auth become common. Given the brute force mitigation in place for password auth, I'm pretty comfortable with password auth security on Android (even with fairly weak passwords -- barring shoulder surfing attacks), so maybe the token makes sense as a way to strengthen the inherent weaknesses of consumer-device biometric auth.

      If it makes sense to require password + token, then perhaps some other backup option could be implemented. Maybe a set of randomly-generated one-time-use passwords like the backup 2FA passwords for Google account auth. In the event you lost your token, you could pull the printed backups out of your wallet and enter one along with your password. Maybe.

      And I wonder if we could even go so far as to use this 2FA token as part of Android Keystore authentication-bound key unlocking, as well as for device unlocking. I could see applications wanting to create keys which can only be used if (a) the user has authenticated themselves in the last X minutes and (b) the token is still in range. This is tricky because the secure hardware used to manage keystore keys probably doesn't have access to the Bluetooth stack... but it might be okay if the token presence requirement were enforced by system software rather than secure hardware. Hmm.

      As a more-secure alternative to a BLE token, a smartwatch could be used as the token.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  21. FIDO = Basically the NSA backdoor lobby by Anonymous Coward · · Score: 1

    Anyone who read the news about the NSA leaks, still has all the alarm bells go off, whenever he hears the name "FIDO".

    It was synonymous with "backdoored, as required".
    I hardly think this got any better.

    Sorry, the NSA is in one category with China, the FSB, Mossad, GCHQ and maybe less evil than North Korea but far more powerful and anti-American to be frank.

  22. FIDO means.... by Anonymous Coward · · Score: 0

    Stop appropriating already used acronyms. Fido is for FidoNet.

    https://en.wikipedia.org/wiki/FidoNet

    Like MS taking ARM as some azure acronym just to confuse the CPU folks.

  23. Smart card reader by tepples · · Score: 1

    Smart cards have enabled [signing communications off the main CPU] for at least a dozen years and counting. They also happen to cost four times less than current USB sticks.

    Even when you include the cost of a smart card reader that connects to one of the ports on the outside of a smartphone, tablet, or laptop computer? On my laptop, counterclockwise from top left, these are power, HDMI, USB, microSD, audio, USB, and USB. Last I checked, Square was charging $35 for a smart card reader that connects to a TRRS audio port, and I imagine that Square's might support only EMV application, not TLS application. If a consumer product computing device does have an ID-000 sized smart card slot, it's probably intended solely for authenticating to a cellular carrier, not to a particular website. Replace it with the card containing your bank's TLS certificate, and you no longer have Internet access through your device's cellular radio.

    As you've probably guessed: I have no experience with ISO/IEC 7816 smart cards other than using the EMV chip on my credit card at merchants and inserting a SIM into a phone.

    1. Re:Smart card reader by WaffleMonster · · Score: 1

      Even when you include the cost of a smart card reader that connects to one of the ports on the outside of a smartphone, tablet, or laptop computer?

      USB card readers are $10-20 if you don't already have one. Individual cards run $0.50 - $1.00 /ea. OTG adaptors sold separately.

      Not only is it cheaper having card readers be the interface people interact rather than raw USB improves system security.

      A trojan authenticator plugged into a USB port can own a system in seconds.

  24. Most so-called "people" are mentally ill. by Anonymous Coward · · Score: 0

    They just think it's normal because de-facto it is. But only because "normal" means "what people usuall do". It is still utterly insane.

    But hey, so is calling mass-murderer " heroes", not calling "profit" theft, thinking women are attracted by money, believing that seeing a penis will harm a child, acting like this is a democracy and TV news are honest neutral facts, and electing somebody from the "Democratic" or "Republican" party.
    Yet they are all at the core of US-American culture.