5 ms·

Not a bad idea but the chief drawbacks I see: 1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a lon

by abalone 12y ago

Not a bad idea but the chief drawbacks I see: 1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client! 2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts. Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in. I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers. [1] https://chrisdecairos.ca/one-time-passwords-pt-2/ https://chrisdecairos.ca/one-time-passwords-pt-2/

PythonicAlpha 12y ago
For your #1: For sites with low security demands that will be Ok. GMail already does it. When I enter GMail it always gets me logged in by an cookie and that lasts for a month or so, only after that period, I have to enter my pw again. Of course, when you do some security relevant changes (like changing passwors ;) ... just kidding ... changing eMail adress), a reauthentication is needed. I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much. BTW: I also described a similar idea some time ago in a blog post: http://strategieneu.blogspot.de/2014/06/email-only-registration.html http://strategieneu.blogspot.de/2014/06/email-only-registrat... After I wrote it, that such ideas where discussed at HN even some time ago.
- michaelmior 12y ago
  While Gmail sessions are fairly long-lived, I wouldn't say that this is an example of a site with low security demands. Email is pretty sensitive.
  - PythonicAlpha 12y ago
    Yes it is. But still Gmail sessions are long-lived. I also would not stretch this system to eMail-access. Blame it on Gmail, that they do not enforce more security.
    - mentat 12y ago
      It works because they aggressively monitor for session stealing attempts and immediately shut them down. So it's long lived but with an impressive amount of monitoring that really isn't within reach for non-Google companies.
      - kuschku 12y ago
        I can tell you: They do not. I made a small program to access Google Keep automatically. Because I was too lazy to implement proper authentication, I just hardcoded my session keys. The app is started from a different IP, using a different user agent and is STILL able to access the site after weeks! (Nowadays I have proper authentication in there, but it’s still worrying that stealing sessions from Google is so easy. Especially because some Google services submit their sessions keys via HTTP, without SSL)
        abalone 12y ago
        That is not enough evidence to conclude that Google does not monitor for session stealing. Lots of people have dynamic IPs and user agent strings are easily spoofed. They're going to be looking at other factors, like where the IP is located.
        mentat 12y ago
        I can tell you they do. Within seconds of clicking on a compromised URL they had locked down my account requiring a text to unlock it. I was deeply impressed.
      - PythonicAlpha 12y ago
        I don't think, that such a scheme can work, when somebody else is using my laptop. Sometimes the simplest attacks are the most effective.
asdfaoeu 12y ago
> Authentication is or should be a much more common event than recovering a lost password For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.
- jordanpg 12y ago
  I think a lot of people do this for infrequently visited sites, but: 1. It generates at least 3 new database transactions each time it happens, not to mention the associated crypto requirements and email. 2. This password recovery system is a common attack vector and vulnerable to social engineering attacks and MITM attacks. 3. It is mostly obviated by the existence of password managers. For those with the knowhow to do this sort of thing, all of this sort of stuff should be happening on the client side.
  - kuschku 12y ago
    3) is not really useful if you login quite often from different devices that aren’t synced, so you can’t use a password manager.
    - Shivetya 12y ago
      well if your password manager is cloud based or each device knows of the others existence you could pull it off. I would not mind the later.
kijin 12y ago
> a better way to solve this is at the browser/OS level with built-in password generation and management I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon. KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time. About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists. [1] https://news.ycombinator.com/item?id=5743057 https://news.ycombinator.com/item?id=5743057
espadrine 12y ago
I feel like we're missing the elephant in the room. The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work. This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons. But the real authentication happens when you enter your password to access your email. Therefore, when I read: > I think a better way to solve this is at the browser/OS level with built-in password generation and management. All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there? We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is. Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one). Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules). From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system. So, is it really a better way to solve this? Not currently.
- ap22213 12y ago
  A few thoughts about the current de facto authentication 'standard': 1. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part. 2. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better. 3. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less. 4. But, sometimes I want to authenticate anonymously. 5. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information. 6. And, if I lose or break my phone, I don't want to lose my identity - I want an easy way to encrypt and store my identity at multiple backup locations.
wtbob 12y ago
The long log-in duration doesn't really bother me in and of itself. No-one uses my computer without my permission, and no-one uses my browser, period (I create new accounts for people). If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
- abalone 12y ago
  That might work for you, but not everyone. General website authentication systems need to work for the masses. And the whole point is shortening the session makes this system very inconvenient to use.

by abalone 12y ago

PythonicAlpha 12y ago

For your #1: For sites with low security demands that will be Ok. GMail already does it. When I enter GMail it always gets me logged in by an cookie and that lasts for a month or so, only after that period, I have to enter my pw again. Of course, when you do some security relevant changes (like changing passwors ;) ... just kidding ... changing eMail adress), a reauthentication is needed. I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much. BTW: I also described a similar idea some time ago in a blog post: http://strategieneu.blogspot.de/2014/06/email-only-registration.html http://strategieneu.blogspot.de/2014/06/email-only-registrat... After I wrote it, that such ideas where discussed at HN even some time ago.

michaelmior 12y ago
While Gmail sessions are fairly long-lived, I wouldn't say that this is an example of a site with low security demands. Email is pretty sensitive.
- PythonicAlpha 12y ago
  Yes it is. But still Gmail sessions are long-lived. I also would not stretch this system to eMail-access. Blame it on Gmail, that they do not enforce more security.
  - mentat 12y ago
    It works because they aggressively monitor for session stealing attempts and immediately shut them down. So it's long lived but with an impressive amount of monitoring that really isn't within reach for non-Google companies.
    - kuschku 12y ago
      I can tell you: They do not. I made a small program to access Google Keep automatically. Because I was too lazy to implement proper authentication, I just hardcoded my session keys. The app is started from a different IP, using a different user agent and is STILL able to access the site after weeks! (Nowadays I have proper authentication in there, but it’s still worrying that stealing sessions from Google is so easy. Especially because some Google services submit their sessions keys via HTTP, without SSL)
      - abalone 12y ago
        That is not enough evidence to conclude that Google does not monitor for session stealing. Lots of people have dynamic IPs and user agent strings are easily spoofed. They're going to be looking at other factors, like where the IP is located.
      - mentat 12y ago
        I can tell you they do. Within seconds of clicking on a compromised URL they had locked down my account requiring a text to unlock it. I was deeply impressed.
    - PythonicAlpha 12y ago
      I don't think, that such a scheme can work, when somebody else is using my laptop. Sometimes the simplest attacks are the most effective.

asdfaoeu 12y ago

> Authentication is or should be a much more common event than recovering a lost password For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.

jordanpg 12y ago
I think a lot of people do this for infrequently visited sites, but: 1. It generates at least 3 new database transactions each time it happens, not to mention the associated crypto requirements and email. 2. This password recovery system is a common attack vector and vulnerable to social engineering attacks and MITM attacks. 3. It is mostly obviated by the existence of password managers. For those with the knowhow to do this sort of thing, all of this sort of stuff should be happening on the client side.
- kuschku 12y ago
  3) is not really useful if you login quite often from different devices that aren’t synced, so you can’t use a password manager.
  - Shivetya 12y ago
    well if your password manager is cloud based or each device knows of the others existence you could pull it off. I would not mind the later.

kijin 12y ago

> a better way to solve this is at the browser/OS level with built-in password generation and management I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon. KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time. About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists. [1] https://news.ycombinator.com/item?id=5743057 https://news.ycombinator.com/item?id=5743057

espadrine 12y ago

I feel like we're missing the elephant in the room. The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work. This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons. But the real authentication happens when you enter your password to access your email. Therefore, when I read: > I think a better way to solve this is at the browser/OS level with built-in password generation and management. All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there? We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is. Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one). Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules). From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system. So, is it really a better way to solve this? Not currently.

ap22213 12y ago
A few thoughts about the current de facto authentication 'standard': 1. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part. 2. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better. 3. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less. 4. But, sometimes I want to authenticate anonymously. 5. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information. 6. And, if I lose or break my phone, I don't want to lose my identity - I want an easy way to encrypt and store my identity at multiple backup locations.

wtbob 12y ago

The long log-in duration doesn't really bother me in and of itself. No-one uses my computer without my permission, and no-one uses my browser, period (I create new accounts for people). If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.

abalone 12y ago
That might work for you, but not everyone. General website authentication systems need to work for the masses. And the whole point is shortening the session makes this system very inconvenient to use.