1. 14
  1.  

  2. 3

    I am still confused how it is even accepted in the USA that a banking website allows you to do whatever to your account by means of some password people are likely to use in many places. Here in Belgium we also have online banking, but you are provided a card reader by your bank to use it.

    In order to do anything online to your account, you need to have your card, the card reader and your card’s pin code. Logging in requires you to receive a challenge number from the bank’s website, you slide your card in the reader, enter the challenge number and your pin code in the reader and receive another number that you enter in the bank’s website. You repeat this process when making a payment or something similar.

    I know, it’s more cumbersome. I do feel rather secure with it though.

    1. 1

      Some swedish banks use as similar system.

    2. 2

      If you do this, consider that I don’t read my email on every device I browse the web with. In particular, it means I will never use your service from a friend’s computer.

      1. 2

        Yes, but perhaps we shouldn’t be allowing that behavior for a truly secure account anyway.

        1. 1

          You don’t have to read your email on your friend’s computer. If you have a smartphone, you can receive the one-time password in your smartphone email application, and then enter it into your friend’s computer. Of course, for this to work, the one-time password should be relatively short and easy to type (use base32).

        2. 2

          This is an interesting idea because you eliminate the possibility of indirect password compromises through password re-use. Unfortunately you replace it with a new point of failure in the form of your “secure channel”, but that point of failure is on the user end rather than the server, so it’s harder to compromise multiple users at once with a server-side data leak.

          I still think 2FA is more secure in general, but I can see the argument that this is a more secure single-factor than a password.

          I don’t like the active request-token workflow like a password reset, though. Something time based like [TOTP] (http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm) seems like a better idea.

          1. 2

            Two-factor auth is definitely more secure. Or at least it can’t possibly be less secure unless you really mess it up by e.g. sharing the password from the first factor using the second factor. But in general two factors will always be more secure than one.

            The idea is that if you are only implementing a single factor, it should be the “something you have” factor (i.e. a code sent to you over a secure channel or a TOTP as you suggest) and not the “something you know” factor.

          2. 1

            Dropping passwords and replacing them with one-time passwords sent through a secure channel is a good solution for some applications. The obvious channel is the email. Unfortunately, most SMTP transmissions still don’t use STARTTLS and thus are unencrypted. This implies that the application and the user have to trust the email server of the user, but also the whole network between the application server and the email server of the user! This is too much trust for most applications. It can work if you can make sure STARTTLS is used or if you use OpenPGP or S/MIME (but this last option is unrealistic for most users).

            1. 1

              I’m basically doing this anyway. I started using LastPass and generating longer, more random passwords for every service. If I don’t have LastPass on the device I’m using then I just reset the password to login.

              1. 1

                I really like ideas about password less system. I even wrote a post about it (http://pothibo.com/2013/08/building-a-password-less-system-part-one/)

                I believe that in the end, it’s a matter of knowing what to trust. I have an alpha that I built on OS X that would use url schemes to communicate with a small application you would have installed that would store a secret, the small application would then prove to the server that the computer is authorized to log in to that account and via websocket, the server would tell the browser that it’s authenticated and let it refresh to access secured content (Do I make sense?)

                Marco Arment did implement something like what this article is about for his latest product (can’t remember, sorry).

                1. 1

                  This sounds a lot like Mozilla Persona, which I think is a pretty great proposition.