Password-less login
medium.com
medium.com
> Rebuttal: This is possible in a password-ful login setup via the forgot password flow. Sometimes there are additional “security questions” but this is typically easily found information.
The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in.
In an ideal world, one could prevent another from gaining access to an account, service, etc. When you can't prevent something, the next best thing is detection. Here, you've just removed the ability for a user to detect that their account is compromised -- and worse, you're trying to spin it like it's a good thing.
Also, greylisting.
Also, what if I wanted to log in to my account from my phone or a mobile device? I choose not to receive e-mail on my phone (only alerts/notifications) and I'm certainly not the only one.
It sounds like someone pitched this idea at a meeting ("Hey, I know! No passwords!") and the next 10 minutes was spent rationalizing all its problems away before declaring it as the one true solution.
I am assuming the indicator would be an email from a service stating password reset but if the person has access to your email account, the obvious thing to do would be delete such an email. There is no difference.
Passwordless login is basically piggy backing on the security of the email account. You'd have to login to a site anyway but you are just logging in to your email which is assumed to be protected better.
My primary email uses greylisting to combat spam. This means that if we receive a mail from an unfamiliar mail server, it's getting an error message saying the mail can not be delivered at the moment, and to come back later. Properly configured servers try again several minutes later. Spam bots seldom try again, so it works well.
I can see how greylisting and tokens that expire quickly can be a problem. Particularly if you have multiple servers for outgoing mails, so that the second mail attempt may come from another IP than the first.
That's exactly why you only store password hashes in the DB. Come on, this is a solved problem!
> Pro: less implementation effort
Sure. But how much of your app's total dev effort is it? Nothing.
I hate the UX of having to log in by email.
> That's exactly why you only store password hashes in the DB. Come on, this is a solved problem!
Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)?
No, you can't compute the password from the hash.
https://arstechnica.com/security/2012/12/25-gpu-cluster-crac...
If your users passwords are sufficiently weak (and let's face it - they are) they can likely be brute forced and then matched against leaked hashes, no matter how strong your salt and hash. If you've got good users who only give you "typically" weak passwords, weak unsalted hashes will still expose said passwords.
Use a strong hash. Perhaps run multiple times, bcrypt style. Salt correctly, and per-user. Somehow convince your users to actually use strong, non-reused passwords. Perhaps then there's no danger to leaking the hashes - but I'd perhaps err on the side of caution and not make the password database publicly readable nonetheless.
I'm not sure what you mean by having access to the system. If you have write access to the database you can just change the user's password to whatever you want.
With almost all current systems the place security really needs to happen is at the email provider. If you can hijack/intercept a users email or hack their account then it's game over with a password anyway, thanks to password resets being (almost) universally done over that channel.
There's an argument that this is no bad thing as security focused email providers could potentially provide very secure access as part of their core business (unlike a startup just trying to get going).
But there's still something bugging me about this implementation I can't put my finger on.
This relies on email, which is highly secure, smtp is not spoof-able, server and mail origins are traceable and verifiable and there is no way to intercept the message on a malicious router/switch whatever. Ow wait ...
That would secure the channel and the website would be able to trust that whoever is clicking the reset link is the owner of the key.
It would also be a nice second factor. You have to have access to the email account and to the private PGP key. And it is a second factor I can fully control, unlike SMS. And it's simple and cheap for the service.
My normal login only needs to see about 10 days of email, I could re-auth or use a bigger PW to get into the whole archive.
Isn't this implementation kind of a really basic idea of what mozialla persona was getting at? https://wiki.mozilla.org/Identity/Persona_Shutdown_Guideline...
Apple has UI in App Store submission that lets you provide App Review with a demo account username/password combo, but only that.
So to highlight another drawback: sometimes being able to share login credentials is a feature. Part of me thinks this ought not to be the case, and I hope I will be able to stick with password-less login.
The downsides I can think of in that case are an attacker attempting to log in at the same time, or -- more generally -- a user thoughtlessly clicking the link when an attacker is trying to log in.
The first problem can be addressed by displaying a second readable token on the login screen which the user should verify is present in the email before they click the link. That is how banks and other high security systems do it here in Norway now when you select authentication via mobile, except they use some sort of mobile communication tied to the sim card instead of email. You get a popup on your phone containing two random words from a dictionary. You confirm that the words match what the browser is currently displaying and then tap "OK".
The second problem can probably be reduced by short token timeouts and using appropriate language in the email to emphasize the implication of clicking the link uncritically.
If anything we should be removing insecure protocols like email, telephone and SMS from the authentication chain rather than relying on them even more heavily than we already do.
I hate to suggest it but authentication via something like WhatsApp might be more secure.
Users don't have to remember passwords, which is a strong benefit, but the user's security is now dependent on the security of their mail provider, or their own security practices in relation to the use of that mail provider, and in all likeliness their smart device.
With the ubiquity of smart devices, this works from a UX point of view and could be really streamlined, but I wonder how much the meme at the top of the article is actually betraying - this is the service provider not wanting to be responsible for your security in relation to their service.
I'm not suggesting that this is unreasonable per se, but the ultimate evolution of this model looks like it could (potentially dangerously) increase the value of a smaller surface area (the smart device) and put a fairly huge onus on the end user understanding and being responsible for their security.
And whilst that seems ostensibly ok, we already know that the weakest link in security is the end user...so this could be putting all your eggs in one basket.
Let me put it this way. In many (but not all) cases I would much rather Google be responsible for my security rather than some random startup whose primary objective is to stay alive, not take security seriously.
Email can be deleted.
Still, a lot of "forgot password" forms seem to be subject to this, too.
Also, you can only have one account per-email -- a disadvantage for some types of service, but admittedly probably a good thing for most.
You'd need to stick it behind a "This website wishes to be notified about email you receive from it" prompt.
But then you'd be able to do all sorts of clever stuff, including streamlining email validation checks and password resets.
Everybody has email. You could create a "Login with Email" function really easily on your website, and it would work for even more users than the "Login with Facebook" option.
Why should everything be done through the browsers, instead of better specialized programs?
Why should protocols designed for one problem be abused to solve other problems?
Why not use client certs instead?
Why should browsers only speak HTTP? Who made that rule?
"Why should everything be done through the browsers, instead of better specialized programs?"
I never said "everything". "Better specialised programs"? What are you talking about? I'm talking about essentially being able to access email from a webpage. There is no "better specialised program" for doing that. I'm not talking about webmail. I'm talking about automated emails.
"Why should protocols designed for one problem be abused to solve other problems?"
What you call "abuse", I call "use".
"Why not use client certs instead?"
This has nothing to do with anything I've mentioned.
Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion.
Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications.
You understand the difference between accessing email and reading email? I'm talking about JavaScript accessing email, and acting on it. You're talking about a human being reading a message.
"Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion."
We're already sending registration emails and password reset links. We currently have a system where the end user has to read an email and click a link in it. My suggestion would just allow us to skip the human part and let the JavaScript read it directly, with a perfect fallback built in for people who don't have their browsers configured to have access to their mail.
"Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications."
Even with certificate based auth, you'd still end up having email involved with registration or password resets in some fashion.
This has way too many security implications which don't make it a reasonable idea:
1. If sites can set up such action, then for that (I don't trust anybody's site to have any form of Access to my emails, except my mail providers per se),
2. if the browsers supply these actions, then for that cause (it would be exploited, or if it would be perfectly secure then it would also be perfectly useless).
navigator.notifyOnEmail({
from: 'sender',
to: 'recipientaddress',
}, (email) => {
/**
* This callback is run whenever a new email
* arrives from sender to recipientaddress.
* Assuming the browser has access to the
* recipientaddress account via IMAP, and
* assuming the sender address matches the
* browser origin and the user has given the
* origin permission to do this.
*/
});How do you know that it really was from that email address?
For an account registration or password reset email, the sending site will typically send you an email with a link inside it containing a secret token. If the JavaScript reads that it received an email with one of those links in it, it will post that information back to the server so the server can complete the function it started (account registration or password reset). Obviously, at that point, it will know if the token it was passed was the one it sent.
[edit] Also, as this system is being implemented from scratch, it could easily be decided that emails which don't pass DMARC for example will simply be ignored. Although I argue that is not necessary.
Then, call notifyOnEmail({from: "login@passwordless.example.com", to: "jean@example.com"}) in every session on your site.
If Jean happened to be logged in, you've just identified her.
Spam filters would probably stop you brute-forcing the address of every visitor, but they might not help if you already have a good guess.
Requiring user approval will stop most of this, although it won't block queries like "are jean@example.com and j@example.net the same person?".
You could do that, but since this isn't a very common login scheme, these might not exist/be popular yet. Also, some of us use password managers that aren't browser integrated, and that further reduces the chance of me having a decent workflow for logging in to the site.
I usually log into such services by doing a password reset every time I visit their service, and this technique at least removes the risk of password leaking.
Will this newspeak fury ever stop?
Never heard of hashing or TLS/SRP?
Password simplicity and reuse (especially across lots of people) is a major problem with password security in data breaches.