81–90 of 392 posts
I play a japanese gacha game and there is no password there for your account. If you want to login they send you a code to your email and then you use that (valid for 30 seconds). I'm not a security expert but I always liked that for some reason
For a login situation with extreme rate limiting (say 3 tries a day) "high entropy" might not involve a lot of randomness. A random 8 character password handed out to a user is overkill. Two random words is overkill. Heck, a single diceware word would take 7 years to guess in that environment. For 100 years you only need something like 4 base32 characters.
The problem with cookies (and “remember this device”) is that the same mechanism is used for remembering things that help the user (that we are logged in) and things that harm the user (ads, tracking). Edit: I’m talking about first-party cookies.
Any time you give developers access to storage on the user device for any reason, you've given them a way to track users. First-party cookies are a decent compromise in my book: you can track users, but you can only track their movements on your own domain.
There is an overwhelming amount of superfluous text in this article. The author's solution: > Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using…
This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager. (I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)
Passkey depends on your device.
> Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generat…
Personal Access Tokens are intended for fully automated access, such as a deployment pipeline. They are not intended for daily use, and step 4 even explicitly says "Need an API token for scripts or testing?". For regular pushing you are expected to use a SSH key, and those are far easier to add.
Earlier quoted context omitted.
Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.
This is why I hope PWAs take off more. If there is an implicit "save first party cookies forever" for PWAs that have been "installed" and we make them discoverable it's a net win.
Earlier quoted context omitted.
This isn’t the attack vector to be concerned about. More concerning is when there’s a data breach and an attacker gains access to hashed passwords. At that point, you attack the hash not the API. This comment is an example of why I wouldn’t want any given website to choose my password.
That assumes the situation where the password hashes are stored in a way that is less secure than the actual data that the attacker ultimately wants access to. That must not be a very common situation. The passwords will not be of any use on any other system. This would eliminate password reuse.
Edit: also, if an attacker dumps all the data today then loses access to the data tomorrow, having access to my password hashes means they can access my account and data later.
We probably will stop one day, but that day isn't yet for many services. There are people who would be unable to use those services if that can't set the password to either the same or a variant of one they always use. In the tech wold we often forget that there is a wide disparity in people's ability to use tech. Take my father, there is no way he could use a password manager, or two factor, it's just never going to…
Your father does use a password manager: a slow, very inconvenient one. If you could teach him to reach for ctrl-c/ctrl-v instead of a pencil, it would be easier for him.
> This step is commonly something like “enter the code in an email we just sent” when trying to login. Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right? > We are literally living through the gradual phase-out of third-party cookie. Yes, and a "remember this device" uses a first-party cookie, so it isn't affected. > My own…