5 ms·

related: wondering if anyone can offer feedback on an idea I've just implemented: We're in the process of building a new app and I was giving serious thought t

related: wondering if anyone can offer feedback on an idea I've just implemented: We're in the process of building a new app and I was giving serious thought to the whole password thing, account creation and lowering barriers to entry. What we've come up with is a means of enabling users to go pretty much password free if they so desire. What we've done is taken the usual email verification/password reset link (something like /keys/65a8c7bc16e759f28d37950664a397d231c552f9) and instead of directing the user to an account setup or password reset page, we use this to authenticate the user and log them into the app. Currently the links expire but I'm toying with extending the length out to a month or more. Users are free to create and use passwords if they prefer. Internally keys are treated like passwords (we use bcrypt) with the exception that a user can have multiple valid keys and keys expire. Weaknesses I can see are - someone who has access to email (physical machine) can log in, will it be a pain to launch an app from an email link (for me, yes, but I've seen users do some very rube goldburgesque things to get to websites). Aside from the physical/email access I think it's probably more secure that the usual users' choice of password

thristian 15y ago
So I can log in as you if I request a magic URL? A magic URL that will be recorded in plaintext in the logs every HTTP proxy and tcpdump between the user and your webserver, and in the history database of every browser they use?
- cubicle67 15y ago
  At the risk of exposing my considerable ignorance, provided this is done over ssl, how is it different from a reset password link or any other information?
  - kgermino 15y ago
    Expiration time, password reset emails are typically one-time-use so it doesn't matter if they're in logs once the user has loaded the page.
    - cubicle67 15y ago
      What if the key was tied to the machine it was first used with? That may get confusing for users though
      - true_religion 15y ago
        IP addresses can be spoofed. You'd have to also place a secret code on each page, and reject form data or user requests (e.g. to delete their data, etc.) if the secret code wasn't submitted.
      - owenmarshall 15y ago
        What happens when someone hits your app from a library computer? From behind a proxy? Have you thought about what happens when their IP changes? Stop. You are inventing a crazy homebrew authentication system here. One great way to absolutely fuck your site's security is through crazy homebrew authentication/authorization/cryptography. Do it right, don't do it yourself.
        sapphirecat 15y ago
        > Have you thought about what happens when their IP changes? ++. When I was walking this road, I answered that question with "I'll use the user-agent instead!" Then I checked that assumption, and the Internet told me that could vary between requests as well. That was the key insight (you can't trust anything) that put me on the road to a much more standard system. (But probably still insecure, since I was younger and working for someone with NIH syndrome.)
      - politician 15y ago
        I previously did some work for an online poker service who had a financial incentive in knowing who was logging in as who and had a custom client with which they could do all sorts of nasty spyware-esque things to the client's machine. And they were still susceptible to hackers. You have a browser for a client and HTTP. Please, don't end up on HN as sadly yet another cautionary tale for doing security wrong.
wccrawford 15y ago
So instead of writing down their password, they write down a URL. It ends up the same both ways.
troyhunt 15y ago
Security by obscurity and a perfect example of failure to restrict URL access: http://www.troyhunt.com/2011/08/owasp-top-10-for-net-developers-part-8.html http://www.troyhunt.com/2011/08/owasp-top-10-for-net-develop... These URLs are exposed in all sorts of places; browser history, proxy servers, web server logs and ISP gateways to name just a few. Never put secrets in URLs and expect it to remain secret. Here's an objective suggestion - put the proposal over on stackoverflow.com and see what response you get.
- gmac 15y ago
  Not that I'm advocating this as a good authentication solution, but the worst sorts of exposures you list (i.e. the ones that aren't restricted to the authicatee's device or the authenticator's server) don't apply if you use SSL. Which of course you do.
- cubicle67 15y ago
  First, it's ssl only. Second, the alternative (which I'm trying to avoid and where this idea came from) is a user being prompted for a password and responding something like "er, um... Password123" or just using the same password they use for everything else The idea was that this may give users a bit more time to think about passwords, and possibly be more secure than the usual passwords. Stating the idea here is giving me some good things to consider
  - mattgreenrocks 15y ago
    Why not use OAuth or something similar so you deal with auth tokens, rather than passwords?
    - cubicle67 15y ago
      Because I'm dealing with exactly the type of users who think 1234 is a great password.
  - deleted 15y ago
    [deleted]
crazygringo 15y ago
I did this with a site of mine a couple years ago, and it worked great. BUT -- because of the site's nature, 1) a hacked/compromised account would have been a minor annoyance at worst, and 2) users weren't expected to log on more than once every month or so. I think it depends very much on your site's profile.
randallsquared 15y ago
I did this for some gold currency systems I wrote a while back (2002-2005), and it worked well. There were some differences. I only allowed one to be active at a time, and inactivated them as soon as they were used (in favor of a session token until the end of the session). Also, users could upload their public key (PGP, GnuPG) and we would then encrypt all email from our system, so between that and SSL-only, I think it was quite secure. I'm in agreement with other repliers that plain text email plus long-lived tokens is a recipe for trouble, though.
cubicle67 15y ago
Replying to myself as it's too late to add an edit Thanks for all the comments. Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. We learn from our screw-ups, not from dong nothing. That said, I think I may have a way of doing things that will allow for easier first-time entry to the app (no "create password" wall) when a user clicks on their email invite link - authenticate them by the email key and log them in, but make this key single use and display a notice visible within the app that they need to set a password at some point before they leave (if not, they'll need to hit the "forgot password" link next time)
- owenmarshall 15y ago
  >Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. I'd actually challenge this assertion a bit. Password management isn't as hard as it should be. I think Bruce Schneier is absolutely right when he encourages users to write down their passwords and store that paper securely -- in a wallet, purse, etc. The problem, IMO, is that we've told users for years to "never write down passwords!" -- when, in reality, we should've been saying "write down a strong password and keep it safe." >We learn from our screw-ups, not from dong nothing. You're braver than I. Screwing up is expected, but security/privacy breaches tend to be among the least tolerated and most remembered screw-ups you can make. If you do decide to pursue some sort of alternative credential system, it's in your best interest to get a consultation from an experienced security professional, as it could save you black eyes down the road.

thristian 15y ago

So I can log in as you if I request a magic URL? A magic URL that will be recorded in plaintext in the logs every HTTP proxy and tcpdump between the user and your webserver, and in the history database of every browser they use?

cubicle67 15y ago
At the risk of exposing my considerable ignorance, provided this is done over ssl, how is it different from a reset password link or any other information?
- kgermino 15y ago
  Expiration time, password reset emails are typically one-time-use so it doesn't matter if they're in logs once the user has loaded the page.
  - cubicle67 15y ago
    What if the key was tied to the machine it was first used with? That may get confusing for users though
    - true_religion 15y ago
      IP addresses can be spoofed. You'd have to also place a secret code on each page, and reject form data or user requests (e.g. to delete their data, etc.) if the secret code wasn't submitted.
    - owenmarshall 15y ago
      What happens when someone hits your app from a library computer? From behind a proxy? Have you thought about what happens when their IP changes? Stop. You are inventing a crazy homebrew authentication system here. One great way to absolutely fuck your site's security is through crazy homebrew authentication/authorization/cryptography. Do it right, don't do it yourself.
      - sapphirecat 15y ago
        > Have you thought about what happens when their IP changes? ++. When I was walking this road, I answered that question with "I'll use the user-agent instead!" Then I checked that assumption, and the Internet told me that could vary between requests as well. That was the key insight (you can't trust anything) that put me on the road to a much more standard system. (But probably still insecure, since I was younger and working for someone with NIH syndrome.)
    - politician 15y ago
      I previously did some work for an online poker service who had a financial incentive in knowing who was logging in as who and had a custom client with which they could do all sorts of nasty spyware-esque things to the client's machine. And they were still susceptible to hackers. You have a browser for a client and HTTP. Please, don't end up on HN as sadly yet another cautionary tale for doing security wrong.

wccrawford 15y ago

So instead of writing down their password, they write down a URL. It ends up the same both ways.

troyhunt 15y ago

Security by obscurity and a perfect example of failure to restrict URL access: http://www.troyhunt.com/2011/08/owasp-top-10-for-net-developers-part-8.html http://www.troyhunt.com/2011/08/owasp-top-10-for-net-develop... These URLs are exposed in all sorts of places; browser history, proxy servers, web server logs and ISP gateways to name just a few. Never put secrets in URLs and expect it to remain secret. Here's an objective suggestion - put the proposal over on stackoverflow.com and see what response you get.

gmac 15y ago
Not that I'm advocating this as a good authentication solution, but the worst sorts of exposures you list (i.e. the ones that aren't restricted to the authicatee's device or the authenticator's server) don't apply if you use SSL. Which of course you do.
cubicle67 15y ago
First, it's ssl only. Second, the alternative (which I'm trying to avoid and where this idea came from) is a user being prompted for a password and responding something like "er, um... Password123" or just using the same password they use for everything else The idea was that this may give users a bit more time to think about passwords, and possibly be more secure than the usual passwords. Stating the idea here is giving me some good things to consider
- mattgreenrocks 15y ago
  Why not use OAuth or something similar so you deal with auth tokens, rather than passwords?
  - cubicle67 15y ago
    Because I'm dealing with exactly the type of users who think 1234 is a great password.
- deleted 15y ago
  [deleted]

crazygringo 15y ago

I did this with a site of mine a couple years ago, and it worked great. BUT -- because of the site's nature, 1) a hacked/compromised account would have been a minor annoyance at worst, and 2) users weren't expected to log on more than once every month or so. I think it depends very much on your site's profile.

randallsquared 15y ago

I did this for some gold currency systems I wrote a while back (2002-2005), and it worked well. There were some differences. I only allowed one to be active at a time, and inactivated them as soon as they were used (in favor of a session token until the end of the session). Also, users could upload their public key (PGP, GnuPG) and we would then encrypt all email from our system, so between that and SSL-only, I think it was quite secure. I'm in agreement with other repliers that plain text email plus long-lived tokens is a recipe for trouble, though.

cubicle67 15y ago

Replying to myself as it's too late to add an edit Thanks for all the comments. Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. We learn from our screw-ups, not from dong nothing. That said, I think I may have a way of doing things that will allow for easier first-time entry to the app (no "create password" wall) when a user clicks on their email invite link - authenticate them by the email key and log them in, but make this key single use and display a notice visible within the app that they need to set a password at some point before they leave (if not, they'll need to hit the "forgot password" link next time)

owenmarshall 15y ago
>Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. I'd actually challenge this assertion a bit. Password management isn't as hard as it should be. I think Bruce Schneier is absolutely right when he encourages users to write down their passwords and store that paper securely -- in a wallet, purse, etc. The problem, IMO, is that we've told users for years to "never write down passwords!" -- when, in reality, we should've been saying "write down a strong password and keep it safe." >We learn from our screw-ups, not from dong nothing. You're braver than I. Screwing up is expected, but security/privacy breaches tend to be among the least tolerated and most remembered screw-ups you can make. If you do decide to pursue some sort of alternative credential system, it's in your best interest to get a consultation from an experienced security professional, as it could save you black eyes down the road.