Password-less login mechanism

[clays]

I came across an article about Web Authentication API and its shenanigan, and I kinda came up with a login or registration without using a password but rather only an email, dropping password mechanism entirely. People forget their email, not to mention their password. Even after they remember their password, password itself is not always a safe form of authentication to deal with. But if I stick with just email or phone to verify their credential, do you think it's as safe (or better) than password?

The flow is simple:
Registration -> Fill email -> User gets email verification -> give link to the logged in homepage/last page.
Same goes to login: Login -> Insert just email -> user gets email verification from the site -> give link to the logged in homepage/last page.

Always sign-in feature is always available, and is only bound to the machine that is verified after the email verification is a success.

Then instead of using password, the user is free to add extra authentication layer such as recovery email, phone, backup codes, and/or USB device through web authentication API. Basically I just want user to only fill a single form which is only email or phone number to create a new account rather than inserting a minimum an email/phone and password.

In my opinion, password era was when people barely has an email as a login method or the app is completely local/offline, and the website (or applications) has to handle the authentication all by itself. It was always "username" and "password", not "email" and "password", and email was just an account recovery extra authentication layer. Email itself is already that "username" and "password" that websites don't even need to have users to do that anymore IF we bound the site to user's email, requiring them to get online to check their email or phone.

The downside is, I still need to have the user to fill that single form, and even probably provide a guide on how to create an email which also guide them through a complete step of verification.

Also, you may ask, why not use "Login with Google" or "Login with Facebook", etc.? Well, some don't prefer to do that at all, as it sounds like we are the third party who let all our data to be shared to them, or us grabbing Facebook/Google data, which can be a hot issue. It also means inefficient 1 or 2 more windows to open, which is verifying what data is shared (which I'd rather put a Privacy Policy link right below/beside the registration/login form to tell which data we are using/tracking), and some troubles dealing with their authentication API themselves. so I don't think relying on third party quick login buttons is better in terms of the feeling of privacy, UX, and dev's trouble dealing with close zero-control of ever-updating third-party buttons in this case, though the advantage is user don't even or barely need to remember anything nor fill any form.

What do you think?

[ShrewdPixel]

I might still be learning some of the canvas libraries, but this stuff is my bread and butter.

I would seriously caution any devs from designing their own authentication system, even if they are quite knowledgeable on the subject, for a simple reason: even large companies get hacked all the time and they have TONS of resources and dedicated personnel to work on these problems. The only reason smaller startups or freelancers get away with it in the short term is through "Security through obscurity", in other words they are too small to show up on the hacker radar or just haven't made any real enemies yet.  ---- OK, enough warnings and on to the info.

While what you are planning isn't that bad of an idea, (here's a link to a web service that does just that.) before building your own I'd read up on User Enumeration and Session fixation attacks as well as reading up on answers to this question at security.stackexchange.com (link to this very question being answered here and as well here). The TL;DR for that is that you are introducing a single point of failure, and there are several different ways to exploit it that you probably have not thought of yet.

It's for this main reason I use other web services for my logins; they have more resources to work out all of the possibilities -- also, if they DO get hacked it's on them and not me or my client.

It's true that Omni-Auth, which is the "sign-in by third party" mechanism I use, is most popular for signing in with Google or Facebook; but it can actually use MANY different options (See list here). While in the past I've been too busy to add more than Facebook or Google for my own sites, on my next project I'll be adding Twitter, Github, LinkedIn, Instagram, and StackExchange. (If one of those doesn't work for the user or dev, there's still a lot of options.) Most notably, it's still the most secure option available for protecting users and devs.

I also highly recommend watching Tom Scott's (Computerphile) videos on Youtube for overviews on "Why to never take passwords" and a few others on things like "SQL injection attacks" to get a better overall idea of what exploits can be used against a site and it's users. Watching just the exploits demonstrated on that channel should be enough to scare the hell out of anyone thinking of making their own (or bypassing an) authentication system.

In summary, while yes you can very well do it, it's almost certainly a bad idea unless you've done a ton of research and thought through every potential possibility. But if it's for a very small site that really doesn't need much security, you can probably get away with it. Just keep in mind that if your site/game does get really successful or gains a huge user base, you'll be scrambling to replace it with something more robust and your users may not react well to the change.

I certainly hope I've at least provided some useful information on this topic. Good Luck!

[clays]

Interesting response ShrewdPixel (and didn't realize there's that LoginRadius already haha, I was just spilling ideas from my head after reading the article). Yeah I'm aware of the basics as I am a web developer myself. With a bit of a maintenance in exchange of better security and popularity as what they confidently can offer, I can fully agree that the 3rd party sign-in is definitely a good choice especially for startups.

In regards of 3rd party login though, it's just I had an experience as a gamer logging into a game using Facebook login, as it is the only medium to login to the game. The game is an online mobile game made by a new company, which was made after a successful stand-alone mobile game he made alone. It then gets into issues quickly where some players complaining that they lose data and all, some also gain no access to the game anymore for unknown reasons as I saw their complaints on the Facebook page. How big, I'm not sure. Not long after that the company made their own authentication method (despite there's no information if that is the case on why they started to make their own), a simple password-based one. But soon after that the complaints get lesser and the company asked the users to backup their data through that login. I can only assume that the Facebook login troubles them, but then again it's only my assumption.

This is not the only game that has issues I faced, I have another but the game company did not seem to take action. Not sure the reason why, whether it's just a small amount or maybe because they already implemented the normal password-based auth in the first place unlike the first game I explained before (uses Facebook login only first).

Okay let's say I narrow it down to password-less and password-based in competition as primary authentication method, do you think the password-less (by email) can replace password-based one? or are they both just the same in terms of security (with their own vulnerabilities) or any other thing you believe could count?

[ShrewdPixel]

It's never my intention to assume the experience level of any user on this board, nor do I ever want to come across as "talking down" to anyone(I see too many knowledgeable users doing that already); I just try to add as detailed of an answer as I can for a forum where users ask questions - please forgive me if I went a bit overboard this time since security is such a Pass/Fail subject I've seen mishandled.

While I don't think either option is that secure, if I was to narrow it down to either the standard password authentication or a password-less method, I'd see the following disadvantages to password-less:

1. The user will need another tab/window open anyway for their email, so if may be more work for some users. 2. Email isn't instantaneous for everyone, so there could be delays to login. 3. In 2-factor authentication, the email verification is the weaker link, and allows man-in-middle attacks more opportunities to gain the email accounts login. 4. It could just wind up in the spam folder for less knowledgable users after too many emails. 5. If the user is on a non-trusted PC, they may not want to even use their primary email. 6. Your email provider will see every login, so Google or FB might still get tracking data anyway. 7. This is the big one for me: (related to #3 )usually most sites are secured with HTTPS, but with this scheme every login requires the authentication link to be transmitted in the clear unless you go to the trouble to send encrypted email or use another protocol.

The advantages to password-less I can see are:

1. With persistent cookies the user could stay logged in on the same machine for up to 30 days if you wish (and the user consents, but this can be done either way). 2. If the user always has their email open, it could be less work for the user. 3. Much like with Omni-Auth, your site doesn't need to keep passwords in the database. 4. It's cleaner and less work for the dev to setup if done simply.

I'd still stick with my initial evaluation: small sites might be able to do this since the security need isn't that high, but if your site takes any sort of payment info (Credit Card, Paypal, Bitcoin, etc for in-game purchases) it would probably be almost suicidal; if I can figure out ways around it, I'm sure someone else even more knowledgeable and motivated than I can.

Here's hoping my discourse on this has been productive and helpful.  

[clays]

45 minutes ago, ShrewdPixel said:

It's never my intention to assume the experience level of any user on this board, nor do I ever want to come across as "talking down" to anyone(I see too many knowledgeable users doing that already); I just try to add as detailed of an answer as I can for a forum where users ask questions - please forgive me if I went a bit overboard this time since security is such a Pass/Fail subject I've seen mishandled.

Ah, it's alright I am not at all thinking of it as "talking down". It's always good reminder to bring up the basics related to it. I was just saying that I was aware of them and I appreciate the relations to the question I posted.

45 minutes ago, ShrewdPixel said:

While I don't think either option is that secure, if I was to narrow it down to either the standard password authentication or a password-less method, I'd see the following disadvantages to password-less:

1. The user will need another tab/window open anyway for their email, so if may be more work for some users. 2. Email isn't instantaneous for everyone, so there could be delays to login. 3. In 2-factor authentication, the email verification is the weaker link, and allows man-in-middle attacks more opportunities to gain the email accounts login. 4. It could just wind up in the spam folder for less knowledgable users after too many emails. 5. If the user is on a non-trusted PC, they may not want to even use their primary email. 6. Your email provider will see every login, so Google or FB might still get tracking data anyway. 7. This is the big one for me: (related to #3 )usually most sites are secured with HTTPS, but with this scheme every login requires the authentication link to be transmitted in the clear unless you go to the trouble to send encrypted email or use another protocol.

The advantages to password-less I can see are:

1. With persistent cookies the user could stay logged in on the same machine for up to 30 days if you wish (and the user consents, but this can be done either way). 2. If the user always has their email open, it could be less work for the user. 3. Much like with Omni-Auth, your site doesn't need to keep passwords in the database. 4. It's cleaner and less work for the dev to setup if done simply.

This is a lot of information, thanks. Come to think of it, after reading the disadvantages you gave, I guess it could also be even more troubling for younger users who barely even have their own email which kinda shift the demographic a bit, probably 12+ or 15+? ? I'm not sure, big web game publishers know this best, haha. As for the advantage it's pretty much what I thought about, I guess I was too focused on user who are used to email even though I do realize the hassle of creating new email just to login to a website or play probably some mini games.

45 minutes ago, ShrewdPixel said:

I'd still stick with my initial evaluation: small sites might be able to do this since the security need isn't that high, but if your site takes any sort of payment info (Credit Card, Paypal, Bitcoin, etc for in-game purchases) it would probably be almost suicidal; if I can figure out ways around it, I'm sure someone else even more knowledgeable and motivated than I can.

Here's hoping my discourse on this has been productive and helpful.  

Surely in reality I agree with you in that case, especially when it comes to payment info (in-app purchases maybe, virtual items).

[ShrewdPixel]

I'd love to hear more opinions offered on this subject; my experience on this primarily comes from setting up database applications for companies that require very strict security for large proprietary datasets and (usually) already have a rather large client base.

I mainly make games for fun and to add to my online portfolio. (Most of my professional work is locked behind non-disclosure agreements, so I can't share it.) That's one reason the first game I've showcased on here was an example MMO; it's easier to integrate the database experience I know. But after our conversation I feel my experience in it has polarized my view on the subject of security and authentication, and I would really like to hear from others who have approached it from different perspectives that might be more practical from a gaming standpoint.

There is a much broader range of situations that can be considered when addressing the practicality of this for the dev and the user, ranging from casual games to MMO's.