How to Fix Authentication: Email as a Password Manager(sakurity.com)
sakurity.com
How to Fix Authentication: Email as a Password Manager
http://sakurity.com/blog/2015/04/10/email_password_manager.html?
2 comments
>(i.e no password reset by the attacker)
Login link = reset link. it's not different from classic scheme. Equally insecure.
"What if" doesn't work, it's 2015 and the problem is still huge. "Use password manager" doesn't work anymore, unless you offer something dead simple as my idea.
Login link = reset link. it's not different from classic scheme. Equally insecure.
"What if" doesn't work, it's 2015 and the problem is still huge. "Use password manager" doesn't work anymore, unless you offer something dead simple as my idea.
"Use a password manager" still seems to be the right answer for frictionless logins. "Easy" is requirement #1 to get people to use a thing. In fact, using it should be easier than not using it.
If you use 1Password, it nails the password details that trip up the "shady" password managers you allude to. See this study about stealing passwords or credit cards from users of auto fill password managers:
https://www.cs.utexas.edu/~suman/publications/suman_pwdmgr.p...
Interestingly, the Safari built in keychain is better to protect cc.
If you use 1Password, it nails the password details that trip up the "shady" password managers you allude to. See this study about stealing passwords or credit cards from users of auto fill password managers:
https://www.cs.utexas.edu/~suman/publications/suman_pwdmgr.p...
Interestingly, the Safari built in keychain is better to protect cc.
you're free to use any password manager. my scheme is for developers to build better authentication
but it just isn't better though. it's worse in the way that developers should be worried about most: security.
How exactly is it worse if it's not different from classic scheme?
you're removing something which people basically understand the concept of - passwords: keep them fucking secret/safe - and trying to replace it with something that is built on top of a system never meant to work that way. If your system routinely sends out OTP emails, all it takes is someone to intercept those emails on their way from your SMTP server out to the wider internet, and every fucking user is breached.
The only reason password reset links are at all acceptable is because they are used relatively rarely and it's not predictable when they will be used.
The only reason password reset links are at all acceptable is because they are used relatively rarely and it's not predictable when they will be used.
So your point is it is less secure because the same weak feature is being used more frequently?
> all it takes is someone to intercept those emails on their way from your SMTP server out to the wider internet it doesn't matter when some user will create a reset request. Because you can do it for him, right?
There are tons of services out there generating a password for you and sending it over in plain text, which is exactly what I proposed. Do we see it heavily abused? The opposite is true - those services are more safe because they got rid of reused passwords.
Also there's a bunch of techniques i didn't describe to prevent some attacks. When user is trying to login save a secret token1 in a cookie and send token2 to their email. When the user clicks this link verify old cookies. This makes passive global wiretapping less useful (if it was your concern). Still vulnerable to more targeted attacks (enter username, wait for email, reuse cookie), but so "reset password" is.
> all it takes is someone to intercept those emails on their way from your SMTP server out to the wider internet it doesn't matter when some user will create a reset request. Because you can do it for him, right?
There are tons of services out there generating a password for you and sending it over in plain text, which is exactly what I proposed. Do we see it heavily abused? The opposite is true - those services are more safe because they got rid of reused passwords.
Also there's a bunch of techniques i didn't describe to prevent some attacks. When user is trying to login save a secret token1 in a cookie and send token2 to their email. When the user clicks this link verify old cookies. This makes passive global wiretapping less useful (if it was your concern). Still vulnerable to more targeted attacks (enter username, wait for email, reuse cookie), but so "reset password" is.
> it doesn't matter when some user will create a reset request. Because you can do it for him, right?
only if I know the user's email address for this given service.
with your system the attacker will get a regular flow of emails like this, and can even just track the emails as they're used, so as to then use them later to create a new authenticated session without arousing the suspicions of the user.
even if an attacker was lucky enough to capture a password reset email, they either have to use it immediately (or it will become invalid) or do a later, second password reset. Either way, the user still knows at the very least that something isn't right.
> There are tons of services out there generating a password for you and sending it over in plain text
and this is fucking atrocious from a security stand point.
> Do we see it heavily abused? The opposite is true - those services are more safe because they got rid of reused passwords.
Care to name some? I'm not aware of any major service, website or application that relies on a OTP via email for primary authentication.
> Still vulnerable to more targeted attacks (enter username, wait for email, reuse cookie), but so "reset password" is.
You still don't seem to accept that knowing your account was compromised is a security feature. With your system there is potentially ZERO indication to the end user that their account has been compromised. That is FUCKING TERRIFYING to me, and that it isn't to you, is even MORE FUCKING TERRIFYING.
Please stop making claims as if you have any fucking idea about security.
only if I know the user's email address for this given service.
with your system the attacker will get a regular flow of emails like this, and can even just track the emails as they're used, so as to then use them later to create a new authenticated session without arousing the suspicions of the user.
even if an attacker was lucky enough to capture a password reset email, they either have to use it immediately (or it will become invalid) or do a later, second password reset. Either way, the user still knows at the very least that something isn't right.
> There are tons of services out there generating a password for you and sending it over in plain text
and this is fucking atrocious from a security stand point.
> Do we see it heavily abused? The opposite is true - those services are more safe because they got rid of reused passwords.
Care to name some? I'm not aware of any major service, website or application that relies on a OTP via email for primary authentication.
> Still vulnerable to more targeted attacks (enter username, wait for email, reuse cookie), but so "reset password" is.
You still don't seem to accept that knowing your account was compromised is a security feature. With your system there is potentially ZERO indication to the end user that their account has been compromised. That is FUCKING TERRIFYING to me, and that it isn't to you, is even MORE FUCKING TERRIFYING.
Please stop making claims as if you have any fucking idea about security.
> potentially ZERO indication to the end user that their account has been compromised
It's not exactly zero. For example you can generate new "security image" every time user logs in. If last time it was some cat and now it's dog, then someone logged in meanwhile. And that's, frankly, is not as terrifying to me as reused passwords.
>Please stop making claims as if you have any fucking idea about security.
I would be excited to see links to your security write ups, please share :)
It's not exactly zero. For example you can generate new "security image" every time user logs in. If last time it was some cat and now it's dog, then someone logged in meanwhile. And that's, frankly, is not as terrifying to me as reused passwords.
>Please stop making claims as if you have any fucking idea about security.
I would be excited to see links to your security write ups, please share :)
You keep making suggestions on the fly which clearly shows you haven't thought this through, and can't accept that its just a fucking terrible idea.
A "security image" doesn't work if it changes every time. First off - you're putting the burden of maintaining security onto the user - how the fuck am I supposed to remember what random picture you showed me?
You can consider this entire discussion thread my fucking security write up.
The comments on your own show that anyone else who listens to you has the same reaction, so it's no surprise you resort to ad hominem attacks implying that only someone with published security write ups is qualified to call your idea fucking stupid.
A "security image" doesn't work if it changes every time. First off - you're putting the burden of maintaining security onto the user - how the fuck am I supposed to remember what random picture you showed me?
You can consider this entire discussion thread my fucking security write up.
The comments on your own show that anyone else who listens to you has the same reaction, so it's no surprise you resort to ad hominem attacks implying that only someone with published security write ups is qualified to call your idea fucking stupid.
I made it on the fly because "know that you've been hacked" is not important at all for regular users. They can't remember a random picture - true, but they also don't care if their password doesn't work anymore. That's all your (and everyone else's) reasoning so far. Why can't you accept that if your email was hacked you will learn about it pretty quickly anyway? (because your paypal funds are stolen).
> that only someone with published security write ups is qualified to call your idea fucking stupid
I didn't say that, your answers are on spot and questions raised are valid, however I am surprised you prioritize "password was changed" issue over entire reused passwords problem for normal users.
To make it clear: you dont care that people reuse passwords and it is a #1 problem, you only care if email account is compromised and if attackers decide to silently spy on one of your other accounts instead of getting the profit now. If that's true we just have different opinions and there's nothing to discuss here.
> that only someone with published security write ups is qualified to call your idea fucking stupid
I didn't say that, your answers are on spot and questions raised are valid, however I am surprised you prioritize "password was changed" issue over entire reused passwords problem for normal users.
To make it clear: you dont care that people reuse passwords and it is a #1 problem, you only care if email account is compromised and if attackers decide to silently spy on one of your other accounts instead of getting the profit now. If that's true we just have different opinions and there's nothing to discuss here.
> I'm not aware of any major service, website or application that relies on a OTP via email for primary authentication.
https://cash.me/account
https://cash.me/account
No, a reset link is not the same as a login link.
If an attacker gets access to my email and resets the password, I know as soon as I try to use the service (because my password won't work)
With your scheme all they have to do is delete the login email and I have no idea they've breached my account.
Also, there is no what if. Safari's password management is absolute real world proof that a good solution is possible.
With your scheme all they have to do is delete the login email and I have no idea they've breached my account.
Also, there is no what if. Safari's password management is absolute real world proof that a good solution is possible.
Ok, i thought you mean you will see an incoming email. Anyway, is it critical to know or not if your account was breached? If it's breached nothing else matters.
Safari manager is probably great, like other managers. But my scheme is for developers not for end users. You can't make everyone use pw managers, but link on demand is super helpful
This can added as an option. Some use password, some use on demand link. Everyone's happy
Safari manager is probably great, like other managers. But my scheme is for developers not for end users. You can't make everyone use pw managers, but link on demand is super helpful
This can added as an option. Some use password, some use on demand link. Everyone's happy
> is it critical to know or not if your account was breached? If it's breached nothing else matters.
This comment is terrifying, given that you are making claims and suggestions about security.
In a normal system I can take action as soon as I know it's breached, to ensure the attacker doesn't have continued access to my account and check/fix damage caused.
With your system an attacker could conceivably have complete access without my knowledge for weeks or months.
Edit:
> Safari manager is probably great, like other managers.
Your entire argument is that password managers are not a good solution - now you're agreeing that they're great. Which is it?
> But my scheme is for developers not for end users. You can't make everyone use pw managers, but link on demand is super helpful
Except users cannot be trusted to make safe choices - our job is to make informed decisions for them, such as requiring passwords, storing password hashes, etc.
> This can added as an option. Some use password, some use on demand link. Everyone's happy
Anyone except the people who are affected by the inevitable breach caused by the use of this non-secure solution. Even if I choose to use a password, I could still be affected negatively by an attacker using someone else's account in a system.
This comment is terrifying, given that you are making claims and suggestions about security.
In a normal system I can take action as soon as I know it's breached, to ensure the attacker doesn't have continued access to my account and check/fix damage caused.
With your system an attacker could conceivably have complete access without my knowledge for weeks or months.
Edit:
> Safari manager is probably great, like other managers.
Your entire argument is that password managers are not a good solution - now you're agreeing that they're great. Which is it?
> But my scheme is for developers not for end users. You can't make everyone use pw managers, but link on demand is super helpful
Except users cannot be trusted to make safe choices - our job is to make informed decisions for them, such as requiring passwords, storing password hashes, etc.
> This can added as an option. Some use password, some use on demand link. Everyone's happy
Anyone except the people who are affected by the inevitable breach caused by the use of this non-secure solution. Even if I choose to use a password, I could still be affected negatively by an attacker using someone else's account in a system.
I will take it as a slight disadvantage. I personally never log out, so I would never know if someone else changed my password while I keep using it on my laptop.
Also remember this scheme is not for advanced users (which care about "was i breached" at all). Advanced users can keep using old password scheme with pw managers.
P.S. There is nothing you can do if your email is breached anyway. I can change it to new email right away.
Also remember this scheme is not for advanced users (which care about "was i breached" at all). Advanced users can keep using old password scheme with pw managers.
P.S. There is nothing you can do if your email is breached anyway. I can change it to new email right away.
a) password managers don't have to be terrible third party solutions. Safari has an amazing password manager with strong random suggestions, and it's just enabled out of the box for millions and millions of iOS and Mac users.
b) this is ridiculously insecure - as soon as anyone breaches your email account they have access to any other service using this scheme, without any way to know (i.e no password reset by the attacker)
a) is proof that this can be "solved" by browser vendors. b) is the reason this should be solved by browser vendors.