Hacker News Reader

Using a 3rd party to login is nice and all but:

- if the party and you don't get along anymore, the accounts are dead. Some business are still counting the money lost from cloudflare deciding the underlying site is not respecting their conditions anymore. Same for Google translate. Auth is no different.

- if it has a technical failure, it's impossible to login. If you think it never happens, think again. We hear about a failure every year for some big companies. Because you don't have access to the code, you can't implement a quick fallback and must wait until they fix it.

- if their 3rd party account is compromised your site is as well. "Someone pirated my facebook" is something I heard to many time. It just meant that a close person from them maliciously used their account by accessing their computer when they were away, gaining access to everything.

- if their API changes, you need to change your code. Meaning you need to follow up on each providers. This can have a huge cost and the GAFAS really don't care and change their API at will.

- if the user closed their 3rd party account, they can't login anymore. This one is terrible : when I closed my gmail account, I became locked out of many services with not way of recovering them.

And then let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.

Basically you own nothing in your infrastructure. You have no control on anything, you are dependent of a lot of things, and they all have you "clicked here to agree" on a lonnnng legal text that will update regularly and be affected by market and politics, across various countries.

Your entire business is at the mercy of others.

All of those are very valid concerns and I agree with you what I tried to express is that some times developers underestimate what it means asking for a username and password in their websites.

For a proof of this, read haveibeenpwned.com. Troy blog is amazing.

If you are an startup, it might be better to invest your time in your idea and not poorly implementing authentication on your own. Yes, google might have issues but I am sure they have more engineers dedicated just to that thing, not only coding but also monitoring.

> let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.

I hear you, I have been in both sides. When we started we used to use everything as a service because we didn't even understand how to manage some things like a database, as our OPs team grew we started to move things inside our infrastructure sometimes just to be able to restart them on failures. It is a trade-off and I guess it has a lot to do with the service you are hiring, SLAs, etc.

> "someone has login across the pond with your password, if is not you please change immediately".

Isn't that exactly what they should do though? They just Spicered their Twitter password...

Yes, some websites will automatically block the attempt and further attempts, other will challenge the user with multifactor auth etc.

Google is sending an email every time you login in a different OS or browser even if you are on the same city.

Which is useless if you don't have push notifications (ie are on iOS, where Google ended push support for Mail.app), because the attacker can just delete the email.

Whenever this happens to me (usually because I'm on a VPN), Google will block my email client from accessing my account until I log into their website and answer a security question. Before, I obviously can't delete the warning. Additionally, the email is also sent to my other address. It's not that easy for an attacker to log in without me noticing. The false positives are annoying, though.

This isn't intended for serious use, it's just intended to raise awareness about the dangers of password reuse. Also, Twitter sent me 2FA SMS messages during testing.

Great work and glad to hear it. Do you have any thoughts on a post-password internet? What are some cool not-password-login-schemes, if you've ever thought about it?

I'm not very good at thinking of technologies that work for non-technical users. Personally, I'm happy with password store + TOTP. Some interesting experiments I've seen include SSH and PGP-based challenges. I would like to see a browser-driven solution like better client-side certificates support, but none of these ideas work well for non-techies.

The vast majority of US government agencies use smartcard certs for authentication to web services, Google uses yubikey. Both are really solid solutions.

Okay, awesome. This makes me contemplate the following: physical identity links (such as yubikeys) are necessary in a real-world situation where credentials need to kept as securely. However, what about cases that do not need such levels of security? It may make sense to have two groups: simple "identity assertion" & secure individual link. Do you feel me? For many of my projects a compromised account would not be disastrous, or any more disastrous than a compromised HN account. It's simply a matter of ease-of-participation that one needs passwords in the first place for many of my applications.

Do you think a "drawable" password would be cool?

Drawable Password = Lock Parttern

everyone uses email for password resets anyway, and most people persist sessions. i always thought we should just email the user a link if their session has expired. there's no reason to have passwords.

this is the scheme sandstorm already uses.

maybe i find this less annoying since i have a dedicated terminal window for my email, and don't have to hunt around tabs for it? do people who use web-based email lose their email tabs?

>i always thought we should just email the user a link if their session has expired. there's no reason to have passwords.

Yes! You are so right. What have I been thinking. This is an excellent and care-free way to do it. I didn't even consider persisting e-mail tokens, but that makes so much sense! Thanks!

An alternative to passwords would be great but giving all my data to google, or to any other 3rd party, is a no go in term of privacy.

What I wish for is an authentication protocol that doesn't rely on a third party. I really like the idea behind SQRL, but it's unlikely to take off. Storing a private key on a reasonably secure platform like an iphone, and that key is used to derive unique keys for each website.

That is part of what U2F is trying to do. The specification is little too complex, but deriving all the site-specific keys from one master secret without any additional token-side storage is one of possible implementations.

But does U2F require a USB device? Where Gibson's SQRL I think is smart is that since it uses a QR code to do the challenge response, it is compatible with every platform, including those that do not have a USB port (think of a corporate workstation where you are not allowed to plug a key, or a MacBook Pro when you don't have the right dongle, or a tablet).

In term of user experience, the website shows a QR code, all you have to do is to show the challenge QR code to the phone, the phone connects to the server directly with the response, and you didn't need to even type a login or password. The security is basically handled by your phone, which if it is an iphone has a fingerprint reader, secure enclave, encrypted disk and wipes out the data when brute forced. Not 100% secure (nothing is) but better than 99.9% of alternatives solutions, including password managers living in Windows, an open environment full of potential malware.

I just wish it had a more consensual / well known sponsor. I think the idea could really work.

I hate it when a service doesn't have a way to use a password but instead forces me to use a 3rd party. Using a 3rd party like google for the password is a breach of my privacy. I do not want to give too much data to facebook or google.

It is a very valid point and I agree with you. This is a known fact; if you sign up with a social account you give up on privacy. When you sign up in a service with a username and password there are a lot of unknowns. Do you know if their understand security at all, if your password is properly stored, if they protect your data from brute force attacks, timing attacks, etc.

True but if I signup with a username and a password, I use a random password, the email I use is specific to that service and I only answer 'security' questions with random data that is then stored in a local password manager.

Now I'll admit this is not the behavior of typical users but I like having that possibility.

So it's better to auth to all sites via Google, than creating a separate login for each site?