You have dealt with them.
Every organization has one of those. Not every, but any organization that cares about legal compliance definitely has one.
The role of information security is a must and it sure can be lonely. They seem to have the company’s best interest at heart, but most developers don’t like sitting in meetings with them. Why?
The familiar refrain of “No!”
It sure feels like an eternity ago, but there was an event three short years ago that had developers and information security all cozy. The reason?
They faced a huge common enemy.
The Heartbleed bug.
The official website in honor of this bug had this to say about the vulnerability
“This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet.”
No kidding!
In simple terms, SSL/TLS — which is key to secure internet communication — had a vulnerability which allowed for easy access to being hacked. The very door created to protect you became the gateway to your worst nightmare.
How do I mean? Well, let’s go back to what the site had to say,
“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content.”
Whao!
You can now see why everyone was freaking out. Definitely, a reason for development and information security to fight on the same side.
These days things are quiet and the only noise you are likely to hear in technology offices is both teams back to bickering and pointing fingers. At least until the next vulnerability. Could Heartbleed have been a none event though?
To answer this it’s worth exploring what people were most concerned about: unauthorized access to user passwords.
Hey Stranger! I know Where you Live and By the Way I have the Keys to Your House
As hinted on already, the biggest concern for lots of folks back then was the risk to user credentials: usernames and passwords.
Notices like below likely streamed through your inbox at the height of this:
Would you feel calmed by getting an email like this?
“Was my data compromised? I don’t see a yes or no in the email!”
That uncertainty breeds anxiety. Yet, since misery loves company you were likely glad this was widespread.
In reality, it was not an actual hack that alarmed experts here, but rather discovery of the bug and the potential for a hack.
During and since this event, many applications took serious measures around security. Information security finally had a voice and everyone had to listen.
From OpenSSL patch updates, to password hashing schemes, to increasing password length and stronger data encryption, securing passwords took center stage.
But, what should have been a moment to innovate resulted in people doubling down on existing practices. No one knows for sure how secure their measures are till the next bug or hack. Why wait to find out. Is there a better alternative?
Could Passwords Not Be Required?
Here is a thought. What if applications never have to use or store your passwords at all? Sounds crazy right?
In reality, you already use applications this way today. What do I mean?
Well, when you try to recover your password, most applications either send you an email with a link or SMS message with some code for verification.
What if that was how you actually signed in not just when you recover passwords? How would this work?
- Enter your email or phone number as your userid
- You get an email or SMS with a code
- Click the link in the email which redirects you to an authenticated session within the app or enter the SMS code which then takes you to an authenticated session
That’s it. No passwords! You can render them obsolete.
A few caveats though.
You might still need a secondary device or means to get this verification email or code. Also, compared to email, you may have a reason to stop using texts for authentication. This is due to the telecom middle man who could also be subject to a hack or social engineering.
As for staying authenticated, you can simply allow a cookie or unique id to be added for that device so that you stay logged in.
Any application that operated in this model would have had no reason to fear Heartbleed compromising user passwords. You simply have no passwords to be compromised.
This idea of passwordless authentication picked up some steam after Heartbleed. It seems to have quieted down a bit.
Also, most folks are simply back to their comfort zone or too busy bickering with Information Security.
Think about it. As a user you never have remember any stinking passwords.
No more dilemma about using your bank password for that website offering free cheatsheet to some random video game.
So, what are the options?
Auth0 (pronounced auth-zero) is a big player in this space. At least if you did a Google search the product is high up on the search results. They provide a way to authenticate through
- One time email (magic) links
- One time passwords (email or SMS)
- Finger print
Definitely a place to start if any of this peeked your interest.
But, for some folks passwords still provide a nice a fuzzy feeling. Besides, this option doesn’t help the fact that you still have tons of applications that don’t have this built in. Well, there may be a way out.
Say Hello to My Little Friend … and He’ll Tell You who I Am and What I’m Capable Of
Enter the world of 3rd party auth.
Ever see a prompt like shown below?
If you are a non-techie, this is called OAuth. With this option a trusted 3rd party application verifies who you are so you don’t have to step through creating credentials to use some random application.
Google, Facebook, Twitter and Github offer this option on many platforms, websites and applications.
You use the existing credentials you have with these trusted 3rd parties to authenticate in a new service or application. If that new service or application gets hacked, they are not left holding the bag of your username and password.
This is cool because if you use Google or Facebook enough you are likely to remember your password there and will not have to worry about some new password else where.
The burden to protect your password is now then on the Googles and Facebooks who offer OAuth. Not only is this convenient (since you don’t have to remember multiple passwords) but it lowers your risk (since you have fewer places to worry about).
No doubt more applications should consider adopting OAuth.
It would be even cooler if there was a service that combined passwordless auth with OAuth. Is there such a mythical application?
There sure is.
Google’s own Firebase.
This platform is totally rad. In addition to offering crash reporting, app hosting, performance monitoring and a realtime database, it offers the ability to authenticate using any one of the credentials you have for
- Gmail
- Github
Additionally, you can use your phone number to get SMS code or use some other none gmail email address/password combo.
With BreadcrumbsHQ user security is top priority which is why we believe that Firebase’s approach wins the cake. You not only get better security but a better user experience.
It would be awesome to go passwordless and we would love to get your thoughts on how you feel about it. In the meantime, we plan to offer the ability to log in with your existing social media accounts.
The Round Up
We live in a scary world where hackers will stop at nothing to exploit technological vulnerability. Why not give them one less thing they can work with?
For app developers, outsourcing auth to such platforms can help you focus on building a true incredible app experience.
A platform like Firebase or Auth0 definitely helps you to ensure better security by doing away with it.
As a user, if you have the option of using OAuth to authenticate via social media accounts, consider it especially if you trust those applications and already use them frequently enough.
I would definitely feel comfortable with Google or Facebook, but you have to decide for yourself.
Using SMS to authenticate is also pretty good, but keep the middle telecom man in mind. A link via your email feels like a better option for passwordless authentication if a biometric option (like fingerprint) is not available.
Here’s to a passwordless future. Here’s to better security and user experience.