In 2020, for many startups, side projects, and companies, using prebuilt authentication systems the likes of Firebase, Authpack, and Auth0 can be ...
For further actions, you may consider blocking this person and/or reporting abuse
I don't understand the whole security auth discussions, not talking specifically about your post, looks like a good overall picture of the alternatives, I talk about the fact that I haven't found any place to dig deeper, go beyond recommendations or overall pictures.
The arguments for new tech in this topic are "just because..", "because is newer" or "because everyone know is like that", and in one hand everyone tells you, don't reuse passwords for multiple sites and a few commas later they talk about "Social Login". I often hear about how some auth methods are insecure because they rely on TSL, so is anyone considering a service without TSL?! or TSL have been broken?, that's a big deal!, way bigger than some random user being impersonated.
I haven't find a source that tells why some tech is weak and weak from what, even basic auth, what's the problem with basic auth?, of course it requires TSL, but you'll have TSL anyway, if not, who cares about the brand of locks you have if you leave your windows open?. And call me paranoid but why would I trust in some company running some non FOSS, non-audited and centralized code? is not the first rule not putting all the eggs in the same basket?.
I honestly don't understand, in this topic I've heard so many mix messages, contradictory statements, unstained claims and hearsay.
Even though there aren't any blatant problems with traditional authentication, there are some areas that can be improved. Often times, these are less focused on improving security and rather on providing an enhanced user experience. But when these attempts boost both security and the user experience, and they are effective cost-wise, then they are a good solution.
For example password-less authentication enhances the user experience greatly, and with an improvement on security. A random key is way more secure than any eight character password or even a 16 character password.
I understand that there's nothing wrong with the standard, but trying to improve the standard is how innovation forms. Even if these aren't good enough alternatives, eventually something that blows traditional auth out of the water will come.
I do agree with the lack of a deeper investigation into these standards. I might attempt something similar in the future, using this as my base to work off of
so in practice how does it works for the user in the password-less authentication? with an intermediary? we are talking about OAuth or alike? is there a way to make it stand-alone? and also what are the pitfalls of having more complex passwords/ransom keys if you limit the attempts or delay them?, because we are not talking about offline encryption nor how the passwords are stored in the DB, those are encrypted with the application keys.
For DID.app specifically, they are implementing OpenId Connect which is an identity layer, on top of OAuth2. As for in practice, DID.app sort of has a demo, when hit you "Get Started".
It is all a very seamless experience. I'm sure if you have concerns with them storing the logins, that you could build your own password-less solution using this protocol.
And because of the way password-less works, I don't think rating limiting would be an issue. The code for me to sign in was valid for 15 minutes and was 28 characters within a char-set of 52 (uppercase and lowercase letters). The possible combinations within that keyspace is
1.1171040382915234e+48. You'd need over a trillion guesses a second to crack that code.oh no, I misspoke, I meant, what is the problem of passwords being shorter if you can limit the number of requests in your API, so what if a password lives in a smaller random space if, as a malicious attacker you can only check 1 each second?, the goal is not to have more possible permutation, the goal is that it takes a long time, having a lot of permutations is the only choice for offline encryption because you can't control how fast an attacker can check, but with a live system you can, you just need to restrict the attempts, in number of tries or time between them.
I also wonder why or if I should force users to have certain degree of security, why can't a user be able to have an unsafe passwords?, if it will only affect themselves I think is their choice, not mine. Now, if that user could affect others, like someone with an admin permissions, of course, you may want to force them, but what if I don't care about my emails or YT, why should I be forced to have a long password, are Google gonna check if I have my passwords in post-its in my monitor?, check that I haven't give them to anyone? why should they care?.
Sorry about the pestering, maybe my questions need it's own discussion post. :)
It's okay. I think that there is nothing wrong with password security, and brute-force protection works very well. But, random passwords are still more secure. Even though they aren't necessary currently, it is always helpful to be one step ahead.
Either way, the security isn't the main focus. It's just a benefit of using it. I think the main benefit of password-less authentication is a much improved user experience
Good post! I did a few projects with Auth0 and it saved a good amount of time, especially when I think about the bugfixing that I didn't have to do later, haha.
At the moment I'm looking into AWS Amplify, which offers authentication based on AWS Cognito.
Thanks
DID is something very interesting. Thanks for writing.
Thank you, that was a good read. I wasn't aware of password-less authentication. Does that link in with 2FA at all or is it exclusively an alternative to normal password authentication?
I can recommend the keycloak if your app works in private network (or you have to integrate with ldap or other user manager system)