Passwords are obsolete(medium.com)
medium.com
Passwords are obsolete
https://medium.com/cyber-security/9ed56d483eb
67 コメント
Is sms channel really secure? Isn't it a plain text channel, as opposed to an unencrypted channel?
Am I the only one who thinks that launching my e-mail client, getting mail, probably scratching around in the Spam folder etc sounds like a fairly hellish user experience?
Mozilla Persona authenticates you using your email without the need to check your email every time (and without the need to enter your email password if you are already logged in).
Persona is awesome for that, and for the "no central authority" thing. To bad it lost momentum and seems an awesome relict inside of Mozilla.
Persona is awesome for that, and for the "no central authority" thing. To bad it lost momentum and seems an awesome relict inside of Mozilla.
Unfortunately the non-native experience was never very good, and even the example implementers they pointed to were hit or miss for actually working cross browser.
I do kind of hope they use heartbleed to make a second push with it fast, while people are paying attention to the problems with current models.
I do kind of hope they use heartbleed to make a second push with it fast, while people are paying attention to the problems with current models.
Not all passwords are equally valuable. Even if you are subscribed to 268 different services, it's quite likely most of them are not of particular importance to you.
One-time passwords are old as dirt. But they're also susceptible to MITM, and when TLS is vulnerable or you send through a plaintext/poorly encrypted channel (SMS), it especially makes no difference. Then, OTPs turn your mobile device or email address into a single point of failure, thus raising interest for their compromise.
One-time passwords are old as dirt. But they're also susceptible to MITM, and when TLS is vulnerable or you send through a plaintext/poorly encrypted channel (SMS), it especially makes no difference. Then, OTPs turn your mobile device or email address into a single point of failure, thus raising interest for their compromise.
This entire article assumes that "it is pretty inconvenient to have to put every single one of them into a password manager" and then goes on to make that case that it's preferable to check your email account or phone for a temporary password???
Just from a UX perspective - security aspects aside - this is worse by a magnitude. Password managers are nowadays a single click in your browser. Use them.
Just from a UX perspective - security aspects aside - this is worse by a magnitude. Password managers are nowadays a single click in your browser. Use them.
The article also assumes you're not providing an email service...
My issue with how things work currently is that logging into a native mobile app is not nearly as easy as logging into a website. That process has to improve. That why I like logging in with Facebook, Twitter or GitHub.
Still what I would prefer is a single trustworthy service which does not compromise my privacy for the purpose of advertising. I could use that service to log into any service which would integrate with this single service to get a one-time password to the user on the computer or mobile device they are using.
As the user I would be able to use an mobile app and browser plugins to get the one-time password to conveniently log in with as few steps as possible.
Still what I would prefer is a single trustworthy service which does not compromise my privacy for the purpose of advertising. I could use that service to log into any service which would integrate with this single service to get a one-time password to the user on the computer or mobile device they are using.
As the user I would be able to use an mobile app and browser plugins to get the one-time password to conveniently log in with as few steps as possible.
The problem clearly lies with mobile platforms that lack any option of extendability. This is by design, and as usual, at the expense of your privacy and security.
> Just from a UX perspective - security aspects aside - this is worse by a magnitude.
This is not true, clicking a link in an email, or copying a number from an sms is much easier than first logging into my password manager, finding the entry and then copy it into the field.
Also, this also works for apps as well, not just the browser.
Besides, password manager usage might still be quite low. So what the writer advocates is not less secure than having a single password for almost all their websites, like most people have.
This is not true, clicking a link in an email, or copying a number from an sms is much easier than first logging into my password manager, finding the entry and then copy it into the field.
Also, this also works for apps as well, not just the browser.
Besides, password manager usage might still be quite low. So what the writer advocates is not less secure than having a single password for almost all their websites, like most people have.
LastPass doesn't require copy-paste on many websites- it can fill on click, or automatically. It's slick and very fast. I leave it logged in so I don't need to type my master password more than once every few days on my home machine. The newest LastPass version on Android can auto-fill in apps, too.
On websites that I've enabled 2FA on, I let LastPass autofill (no clicks) and pulling up Google Authenticator on my phone is what takes time.
The problem with using SMS as your only authentication is, what do you use for your second factor? I suppose a PIN would work.
SMSes are also trivial to intercept: imagine the national telco silently routes some login SMSes that were going to a number on a list to the local internal security agency. The user just gets no SMS (or a code that doesn't work), assumes something went wrong on the network, and asks for another one. Meanwhile the "baddies" have logged in already and snaffled up the information they want.
What I want is to be able to use Google Authenticator as my only authentication, plus a PIN for slightly sensitive sites and a long password for very sensitive sites (and to disable my phone from a distance).
On websites that I've enabled 2FA on, I let LastPass autofill (no clicks) and pulling up Google Authenticator on my phone is what takes time.
The problem with using SMS as your only authentication is, what do you use for your second factor? I suppose a PIN would work.
SMSes are also trivial to intercept: imagine the national telco silently routes some login SMSes that were going to a number on a list to the local internal security agency. The user just gets no SMS (or a code that doesn't work), assumes something went wrong on the network, and asks for another one. Meanwhile the "baddies" have logged in already and snaffled up the information they want.
What I want is to be able to use Google Authenticator as my only authentication, plus a PIN for slightly sensitive sites and a long password for very sensitive sites (and to disable my phone from a distance).
No, you're just using a poor password manager. For example, 1Password integrates into your browser making password lookup and form filling a key-chord away. At most, you'll also need to authenticate with it for your current session, turning it into a two-step process which still takes less than ten seconds.
But either way it's much more preferable to waiting x minutes for your authentication link to appear, and then having to copy and paste. The fact you have to wait an indeterminate amount of time for your auth email/sms to come through means it's a totally sub-standard solution, bordering on the ridiculous.
But either way it's much more preferable to waiting x minutes for your authentication link to appear, and then having to copy and paste. The fact you have to wait an indeterminate amount of time for your auth email/sms to come through means it's a totally sub-standard solution, bordering on the ridiculous.
The writer is also incorrect about the nature of obsolescence. Something only becomes obsolete when a better system prevails and the old system falls out of use.
This has not happened, and if it ever does it probably won't look anything like what the author proposes.
This has not happened, and if it ever does it probably won't look anything like what the author proposes.
Does this apply even on mobile?
I'm interested in a password manager that works seamlessly on Android.
I'm interested in a password manager that works seamlessly on Android.
The problem with this is that it's not as convenient as passwords and people hate things that are even slightly inconvenient.
Typing a username and password is very fast assuming that you remember them both (even faster with a password manager). Now you have to log in to your email every time you want to log into any website. This is especially inconvenient if you are a webmail only user. Or you have to get a code sent to your phone which you have to retype if you want to use the website on a different device.
What happens if your email provider goes down, or your phone isn't working?
Typing a username and password is very fast assuming that you remember them both (even faster with a password manager). Now you have to log in to your email every time you want to log into any website. This is especially inconvenient if you are a webmail only user. Or you have to get a code sent to your phone which you have to retype if you want to use the website on a different device.
What happens if your email provider goes down, or your phone isn't working?
>The problem with this is that it's not as convenient as passwords and people hate things that are even slightly inconvenient.
This is generally true but I wouldn't go that far.
One example of something that is more than 'slightly inconvenient', while being introduced globally fairly recently, is captchas. Sure, nobody likes them but it isn't like people have boycotted sites that have them.
(another example would be requirements for longer passwords with digits and mixed letters in them - a requirement that was mostly non-existent 10 years ago)
Sure, email authentication is probably more inconvenient than my examples, but you can definitely make improvements to it (a browser extension similar to those used by password managers for example can greatly reduce the inconvenience) if it becomes the standard.
This is generally true but I wouldn't go that far.
One example of something that is more than 'slightly inconvenient', while being introduced globally fairly recently, is captchas. Sure, nobody likes them but it isn't like people have boycotted sites that have them.
(another example would be requirements for longer passwords with digits and mixed letters in them - a requirement that was mostly non-existent 10 years ago)
Sure, email authentication is probably more inconvenient than my examples, but you can definitely make improvements to it (a browser extension similar to those used by password managers for example can greatly reduce the inconvenience) if it becomes the standard.
[deleted]
Multi-factor authentication is still required to protect the email.
The only problem I have with two-factor auth on my Gmail is that I sometimes just don't have my phone with me. I don't remember if I could send a confirmation to my backup email address or not. A while ago my Android phone's screen experienced glitch and wouldn't respond. I was in the middle of some important business which required me to access my email. But the screen was dead so I couldn't access either the Google auth nor SMS code on the phone.
The only problem I have with two-factor auth on my Gmail is that I sometimes just don't have my phone with me. I don't remember if I could send a confirmation to my backup email address or not. A while ago my Android phone's screen experienced glitch and wouldn't respond. I was in the middle of some important business which required me to access my email. But the screen was dead so I couldn't access either the Google auth nor SMS code on the phone.
This is what the backup, one time use codes are for. You should keep a set in your wallet, bag, or whatever non-electronic thing you keep with you all the time. I have so far had to use that once in the time since google introduced 2-factor, but man was it ever useful.
Ah. Right. Unfortunately, that's one thing I and probably many people don't ever write down because "writing down 'password' is bad". I probably should do that for my 2-auth since the probability of someone I am familiar with stealing my wallet and attempting to log in my email is probably negligible.
The real problem are password managers. Where you used to have ten keys separately, you now have one key which can access ten keys. But that's not what the user thinks. Convenience over security. If you are using a password manager your attack vector scales horizontally with the amount of registrations you have.
It's not a solution.
It's not a solution.
It is absolutely the best existing solution to today's problem which is company databases being hacked. If you yourself as an individual are being targeted then all bets are off, and you'll probably need something a bit more heavy-duty than is available in off-the-shelf software today.
I don't like this proposal, simply because e-mail and SMS are not secure. Something like SQRL sounds much better to me, in contrast.
> What is the benefit over traditional usernames & passwords?
- There are no usernames or passwords to have compromised, lost or stolen.
- No keyboard interaction, great for using public computers that could log your keystrokes.
- You only need your Master Key, no lists of usernames and passwords to keep track of.
- There is NO WAY to link one person across sites based only on the site-specific public key, websites may ask for more infomation that could be tracked.
http://sqrl.pl/guide/
https://www.grc.com/sqrl/sqrl.htm
> What is the benefit over traditional usernames & passwords?
- There are no usernames or passwords to have compromised, lost or stolen.
- No keyboard interaction, great for using public computers that could log your keystrokes.
- You only need your Master Key, no lists of usernames and passwords to keep track of.
- There is NO WAY to link one person across sites based only on the site-specific public key, websites may ask for more infomation that could be tracked.
http://sqrl.pl/guide/
https://www.grc.com/sqrl/sqrl.htm
Sensationalism at its best. It's "passwordless authentication" except for the fact that you still have to somehow login to your email account.
This sounds less convenient, harder to implement, and no more secure than OpenID, and even that failed to gain traction.
> This sounds less convenient, harder to implement, and no more secure than OpenID
In what way is it less convenient? A standard user has their phone with them...24/7? At least in the sms realm it's more convenient than trying to come up with a password that has: A capitol letter, a number, a special character, a lower case letter. Also way more secure, a user gets sent a message of a one time code looking like 037.820.374.839 the time it would take to guess that, the one time code would have been timed out and the hacker would have been no closer to getting in compaired to a static password.
In what way is it less convenient? A standard user has their phone with them...24/7? At least in the sms realm it's more convenient than trying to come up with a password that has: A capitol letter, a number, a special character, a lower case letter. Also way more secure, a user gets sent a message of a one time code looking like 037.820.374.839 the time it would take to guess that, the one time code would have been timed out and the hacker would have been no closer to getting in compaired to a static password.
Not everyone has smart phones.
Not everyone that has smart phones keep it on them all the time.
Not everyone that has smart phones that keep it on them all the time have a working (charged) phone all of that time.
Not everyone that has smart phones keep it on them all the time.
Not everyone that has smart phones that keep it on them all the time have a working (charged) phone all of that time.
> Not everyone has smart phones.
> Not everyone that has smart phones keep it on them all the time.
> Not everyone that has smart phones that keep it on them all the time have a working (charged) phone all of that time.
What do smart phones have to do with sms?
> Not everyone that has smart phones keep it on them all the time.
> Not everyone that has smart phones that keep it on them all the time have a working (charged) phone all of that time.
What do smart phones have to do with sms?
Disregard that adjective:-p I'm an idiot:(
Not an idiot :) You make a good point that people don't have their phones on them & alive all the time which is where totp can come in with dongle totp's (like http://www.securemetric.com/secureotp-time.php) agreed it costs you a fair amount but if you want secure when you don't have your phone... it's worth it. And then maybe like google have a few longer random passwords that are to use when you don't have your phone or a TOTP/OTP generator.
And here I thought this was going to be clever.
Totally agree, except for the fact that email is a secure medium. Phone would be much better.
Phone is no better than email.
Security through a physical object that can run out of battery, be stolen, have no signal, cost money to have service, offers no cryptography while being under mass surveillance across the world, etc.
I've been looking into JWT tokens (claim that this device is authorized to do something). If there is a breach on server side, you simply replace public and private keys. Each user can also have a different public key.
Registration on User side:
1. Enter email
2. Welcome email with token
3. Save token (password manger, mobile phone, print it...)
4. Use app
If someone steals your token, you simply request new token and old gets immediately invalidated.
It's like Mozilla Persona, but there is no middle man.
Registration on User side:
1. Enter email
2. Welcome email with token
3. Save token (password manger, mobile phone, print it...)
4. Use app
If someone steals your token, you simply request new token and old gets immediately invalidated.
It's like Mozilla Persona, but there is no middle man.
Submitter, please provide a better URL next time. Here we have:
https://medium.com/cyber-security/9ed56d483eb?utm_source=Twi...
i.e. all the twitter campaign garbage. Instead use this:
https://medium.com/cyber-security/9ed56d483eb
https://medium.com/cyber-security/9ed56d483eb?utm_source=Twi...
i.e. all the twitter campaign garbage. Instead use this:
https://medium.com/cyber-security/9ed56d483eb
I wish protocols like TLS-SRP (or SRP as an HTTP auth method?) would become more prevalent. At that point you can authenticate over a clear-text stream and it'd be secure. I don't see any reason we should still be sending secret information to a server like this.
This is quite a stupid idea.
How exactly am I supposed to log into my passwordless email to check the email containing the code to get into my email ?
The assumption that "the ability to send an email or SMS to users reliably and quickly" doesn't mean the user will receive it in a timely manner or at all.
But even assuming this article is actually sound and works as described, would replacing password with email/sms authentication improve the overall security ? I'm not so sure that sending unencrypted email containing authentication data is improving security or that trusting a phone to be handled by its owner at all time is a sane assumption to make.
Then there is the issue of the whole authentication process being turned into the quite annoying and not always working password reset process which often is not handled in a secure manner.
The correct way to fix this stale password issue is simply to revoke passwords and ask users to choose a new one as is usually done when security has been breached.
The assumption that "the ability to send an email or SMS to users reliably and quickly" doesn't mean the user will receive it in a timely manner or at all.
But even assuming this article is actually sound and works as described, would replacing password with email/sms authentication improve the overall security ? I'm not so sure that sending unencrypted email containing authentication data is improving security or that trusting a phone to be handled by its owner at all time is a sane assumption to make.
Then there is the issue of the whole authentication process being turned into the quite annoying and not always working password reset process which often is not handled in a secure manner.
The correct way to fix this stale password issue is simply to revoke passwords and ask users to choose a new one as is usually done when security has been breached.
YubiKeys are quite a good solution to this issue. OTP always, and a unique User ID as well. It can even go so far as plug in the key, press go and you're all ready, no usernames or passwords needed.
YubiKeys still can cost you up to $50, where as TOTP using something like google authenticator(doesn't have to be google auth) costs you? Nothing?
"The basic idea is that instead of using a password to authenticate each user, a temporary secret code is sent to them over a secure channel. "
Secure Channel, like OpenSSL you mean?
Secure Channel, like OpenSSL you mean?
No, you use a shared secret which both you and the server can use to generate a one-time password. You send the OTP (over something like TLS still, yeah) and the server checks that it is valid and makes sure it can't get replayed.
I would go out on a limb and say it would probably be easier to sniff these codes from email and sms traffic than it would be to extract passwords from transient memory via Heartbleed.
Wait, what? So instead of entering a password a password is sent to me via text message or email with a temporary code, sort of like two-factor authentication without the two-factor?
So how do I login to my email account for example if I need to login first to my email and get the temporary password? It's a chicken and egg problem. I can't login to my email to get my temporary code, but I am trying to login to my email.
Somewhat flawed idea in theory, even more horrible in practice. I hope this doesn't become a real thing. I will refuse to use any site that implements this flawed passwordless solution.
So how do I login to my email account for example if I need to login first to my email and get the temporary password? It's a chicken and egg problem. I can't login to my email to get my temporary code, but I am trying to login to my email.
Somewhat flawed idea in theory, even more horrible in practice. I hope this doesn't become a real thing. I will refuse to use any site that implements this flawed passwordless solution.
Woah, hold on.
> sort of like two-factor authentication without the two-factor?
If you don't have 2-factor, which most sites don't, then it is 1-factor. This is replacing that 1-factor with another 1-factor.
> So how do I login to my email account for example if I need to login first to my email and get the temporary password? It's a chicken and egg problem.
You are taking him too literally. While he did say it could replace passwords, he obviously didn't mean email auth. Email auth would probably still require a password. Since many have their email password saved, they may not usually have to enter that anyway, most of the time.
> Somewhat flawed idea in theory, even more horrible in practice. I hope this doesn't become a real thing. I will refuse to use any site that implements this flawed passwordless solution.
You've not presented any valid argument against it. Why is it flawed? If it is horrible in practice then why do many companies use SMS as secondary auth (for the "2" in 2-factor)?
> sort of like two-factor authentication without the two-factor?
If you don't have 2-factor, which most sites don't, then it is 1-factor. This is replacing that 1-factor with another 1-factor.
> So how do I login to my email account for example if I need to login first to my email and get the temporary password? It's a chicken and egg problem.
You are taking him too literally. While he did say it could replace passwords, he obviously didn't mean email auth. Email auth would probably still require a password. Since many have their email password saved, they may not usually have to enter that anyway, most of the time.
> Somewhat flawed idea in theory, even more horrible in practice. I hope this doesn't become a real thing. I will refuse to use any site that implements this flawed passwordless solution.
You've not presented any valid argument against it. Why is it flawed? If it is horrible in practice then why do many companies use SMS as secondary auth (for the "2" in 2-factor)?
The problem is that getting email or SMS and having to type that code in every time, then deleting that email/SMS, manually is less convenient that using a password manager.
You can have an "authentication email manager" just like password managers, but then what have we solved exactly? Nothing.
Except that emails, when used as mass-authentication device, will become an even more attractive target to hackers. In most cases accounts are exploited namely via their email password recovery, not via their password.
Email/SMS are an ok layer when used as a second factor, but on their own, they are less secure than a strong password. While logins are HTTPS, email is plain text, so is SMS.
Heartbleed is an exception. Dropping passwords over Heartbleed is precisely the same type of overreaction we had after 9/11 when suddenly flying became a nightmare (and still is).
The proper reaction here is: Heartbleed is fixed, and we better put some resources towards vetting and fixing OpenSSL so this doesn't happen again.
No need to build towers of nonsense that assume it'll be Heartbleed every week now for the next 20 years.
You can have an "authentication email manager" just like password managers, but then what have we solved exactly? Nothing.
Except that emails, when used as mass-authentication device, will become an even more attractive target to hackers. In most cases accounts are exploited namely via their email password recovery, not via their password.
Email/SMS are an ok layer when used as a second factor, but on their own, they are less secure than a strong password. While logins are HTTPS, email is plain text, so is SMS.
Heartbleed is an exception. Dropping passwords over Heartbleed is precisely the same type of overreaction we had after 9/11 when suddenly flying became a nightmare (and still is).
The proper reaction here is: Heartbleed is fixed, and we better put some resources towards vetting and fixing OpenSSL so this doesn't happen again.
No need to build towers of nonsense that assume it'll be Heartbleed every week now for the next 20 years.
Dropping passwords because of heartbleed is an over reaction. But passwords are hopessly outdated.
People need secure cryptographic hardware tokens (something they have) with a passphrase (something they know).
People need secure cryptographic hardware tokens (something they have) with a passphrase (something they know).
You're underestimating the work that's been done in secure password managers in the last few years.
Check the whitepaper Apple published regarding their iCloud Keychain mechanism.
It generates secure passwords, locks them with a passphrase, but also makes them available on all your devices, not just one (which, if it breaks, you're locked out of all your services).
Using hardware for tokens is secure and simple, but it shows a severe lack of imagination. I only see hardware tokens as useful for very high security logins, like bank accounts, where the apparent inconvenience is at least justified.
Check the whitepaper Apple published regarding their iCloud Keychain mechanism.
It generates secure passwords, locks them with a passphrase, but also makes them available on all your devices, not just one (which, if it breaks, you're locked out of all your services).
Using hardware for tokens is secure and simple, but it shows a severe lack of imagination. I only see hardware tokens as useful for very high security logins, like bank accounts, where the apparent inconvenience is at least justified.
>why do many companies use SMS as secondary auth (for the "2" in 2-factor)?
Because they don't know about TOTP or HOTP, and they instead decided to use a terribly insecure protocol as the basis for user authentication? The onus is on you to prove SMS is better than a shared secret + a nonce.
Because they don't know about TOTP or HOTP, and they instead decided to use a terribly insecure protocol as the basis for user authentication? The onus is on you to prove SMS is better than a shared secret + a nonce.
Ok, valid point- to clarify, when I said 2-factor SMS, I was assuming a 30-second TOTP like Google's.
If you don't use TOTP, someone can login to your account just by knowing the password which they can use from almost anywhere. If you were to only use TOTP, they'd need your phone. To me them stealing your phone is tougher than stealing or guessing your password.
If you don't use TOTP, someone can login to your account just by knowing the password which they can use from almost anywhere. If you were to only use TOTP, they'd need your phone. To me them stealing your phone is tougher than stealing or guessing your password.
That is exactly the point. The author is proposing we replace one thing with another which doesn't fix the problem. There'll just be some other vulnerability with a passwordless approach we'll have to work around. I don't see the point to be honest. Passwords aren't what make web applications and services insecure, nor are they any more of a risk than say sending a user a temporary code to enter to login.
I am taking him somewhat literally because the author and the sensationalist title saying passwords are obsolete. As you pointed out yourself, passwords are not obsolete because how else are we going to login to our email to get our temporary passcodes (if sent to our email)? Any solution which pitches itself like: well you would use it for everything except for the one thing you most likely would care about protecting over everything else, your email.
My argument against this approach is it doesn't solve the problem. Those generated passcodes are being stored somewhere on the server-side, correct? How is what the author proposing any different to that of a securely hashed password? Replace hashed password with hashed temporary code and you get the same results: they're both passwords when you view this proposed solution on a technical level.
To quote a few parts of the article:
Passwords are obsolete because of email and SMS. Specifically, the ability to send an email or SMS to users reliably and quickly. In theory, we’ve had that ability for a long time.
Sending our a passcode via SMS which the author seems to be a fan of costs money. Unless you're the likes of Google, Facebook or Twitter, implementing a solution that costs real money on an already tight-budgeted service is most likely at the bottom of your priority list, if you have thousands of users logging in daily, that's a lot of cash being spent, even if an SMS is cents on the dollar. Why would I implement a solution that is for people too lazy to use a password manager or use strong passwords for the various web services they use?
Adding in functionality that requires use of a third party service also doesn't sit well with me. I have to trust that Twilio or whomever is sending out these SMS's have a secure service that isn't going to allow the wrong people to get passcodes sent from the website because of some API flaw nobody has discovered yet (or heartbleed like attack).
But the recent Heartbleed bug highlights the fact that hacking password reset flows for convenience is not good enough. We need to convince websites to stop using passwords altogether.
As I pointed out, this temporary passcode approach isn't truly passwordless. A hash is being generated on the server side, stored in a database awaiting a user to login. The difference being the server is generating the passcode for you and you're trusting that passcode is secure enough.
I am taking him somewhat literally because the author and the sensationalist title saying passwords are obsolete. As you pointed out yourself, passwords are not obsolete because how else are we going to login to our email to get our temporary passcodes (if sent to our email)? Any solution which pitches itself like: well you would use it for everything except for the one thing you most likely would care about protecting over everything else, your email.
My argument against this approach is it doesn't solve the problem. Those generated passcodes are being stored somewhere on the server-side, correct? How is what the author proposing any different to that of a securely hashed password? Replace hashed password with hashed temporary code and you get the same results: they're both passwords when you view this proposed solution on a technical level.
To quote a few parts of the article:
Passwords are obsolete because of email and SMS. Specifically, the ability to send an email or SMS to users reliably and quickly. In theory, we’ve had that ability for a long time.
Sending our a passcode via SMS which the author seems to be a fan of costs money. Unless you're the likes of Google, Facebook or Twitter, implementing a solution that costs real money on an already tight-budgeted service is most likely at the bottom of your priority list, if you have thousands of users logging in daily, that's a lot of cash being spent, even if an SMS is cents on the dollar. Why would I implement a solution that is for people too lazy to use a password manager or use strong passwords for the various web services they use?
Adding in functionality that requires use of a third party service also doesn't sit well with me. I have to trust that Twilio or whomever is sending out these SMS's have a secure service that isn't going to allow the wrong people to get passcodes sent from the website because of some API flaw nobody has discovered yet (or heartbleed like attack).
But the recent Heartbleed bug highlights the fact that hacking password reset flows for convenience is not good enough. We need to convince websites to stop using passwords altogether.
As I pointed out, this temporary passcode approach isn't truly passwordless. A hash is being generated on the server side, stored in a database awaiting a user to login. The difference being the server is generating the passcode for you and you're trusting that passcode is secure enough.
Why is this article promoting a seriously flawed form of 2 factor auth? SMS based 2fa is easily broken compared to protocols based on a shared secret and invalidated using time or some kind of nonce counter :/
Edit: ah nevermind, it's promoting this as the _only_ factor which is even more idiotic.
Edit: ah nevermind, it's promoting this as the _only_ factor which is even more idiotic.
The irony of this?
Medium asks me to 'sign in' to view the content...
I know this isn't the author's fault
Medium asks me to 'sign in' to view the content...
I know this isn't the author's fault
I've tried the email > login flow, and my experience was that users hate having to check their email to log in. Power users didn't mind, because they often have their email very readily accessible at all times. It was much harder to convince average users that it wasn't an extra layer of effort (a perception problem).
[deleted]
This is poor advice.
This article is written as if it were suggesting two-factor authentication. In actuality it's suggesting a new one-factor authentication. A single factor that my phone company and device manufacturer can access, no less.
On Android, you can give apps permission to read your text messages. The effect, were this author's advice followed, would be that apps get access to all of your other services.
This article is written as if it were suggesting two-factor authentication. In actuality it's suggesting a new one-factor authentication. A single factor that my phone company and device manufacturer can access, no less.
On Android, you can give apps permission to read your text messages. The effect, were this author's advice followed, would be that apps get access to all of your other services.
WTF? Email and SMS are not even remotely secure channels for transmission of data. Granted SMS is harder to get too but your telco typically stores all your messages (for a period of time) for law enforcement reasons and everything is passed in the clear for emails.
You are better off using a trick like this one: http://blog.rabidgremlin.com/2009/12/28/tip-creating-easy-to... to create a unqiue but easy to remember password for all the sites you use. Of course you want to use at least 4 different patterns one for banking, one for email, one social and one for the rest of the web...
You are better off using a trick like this one: http://blog.rabidgremlin.com/2009/12/28/tip-creating-easy-to... to create a unqiue but easy to remember password for all the sites you use. Of course you want to use at least 4 different patterns one for banking, one for email, one social and one for the rest of the web...
And anyone with $1500 and some free time can intercept your GSM communications and read the plaintext anyway. See: http://youtu.be/rXVHPNhsOzo
This is DANGEROUS advice. Email is typically one of the easiest channels to access. There are dozens of ways that someone can get access to your email, it shouldn't even remotely be considered secure.
For low security content it can be acceptable, I've used this method for email subscription centres before, however the only actions a user could do is manage their email subscription and thus it was considered to be acceptable. The idea that this method would be used for a SaaS product that is being paid for is mind-boggling.
Thats not to say it couldn't be used in multi-factor authentication, but tying the only authentication to email is creating a giant single point of failure from an insecure system with a shoddy security history.
For low security content it can be acceptable, I've used this method for email subscription centres before, however the only actions a user could do is manage their email subscription and thus it was considered to be acceptable. The idea that this method would be used for a SaaS product that is being paid for is mind-boggling.
Thats not to say it couldn't be used in multi-factor authentication, but tying the only authentication to email is creating a giant single point of failure from an insecure system with a shoddy security history.
- People heed the advice of this author, and soon all passwords are abolished, replaced with email auth.
- Of course, emails still have a password, as you can't email auth an email.
- Heartbleed 2 happens, hackers focus on Heartbleeding email services.
- For every email password you get, now you have complete control over this person's life, as all services are linked to it for auth.
- Security experts start proposing that you have a separate email for every email auth service, and every email has a separate password, so you can isolate damage.
- Result: previously you had N passwords for N services and 1 email. Now you have N passwords for N services and N emails.
Yay for "improvement"!