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.
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
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?.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.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
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?.