221–230 of 278 posts
Earlier quoted context omitted.
Yes, password managers are way safer than copy-pasting. You don't want something as sensitive as a password in your clipboard buffer, either.
Gah what then? I use strong passwords but almost all of them flow through my clipboard.
Makes them easy to use, with no saved PW.
This is an example of a common antipattern in software: some piece of software fails to correctly implement something (here, modern HTML autocomplete="cc-exp-year"), and another piece of software goes through all kinds of contortions to work with incorrect or incomplete implementations with the result that it now behaves undesirably with a third piece of software. Specifically, 1Password has to do complicated guesses…
I have little faith site developers care about password managers. Many even try to block them from working due to some perceived notion that they are insecure.
But you're right, browsers would have to become picky on saved credit card auto populate to force a change.
Earlier quoted context omitted.
I have little faith site developers care about password managers. Many even try to block them from working due to some perceived notion that they are insecure.
But they (or their bosses) will care if credit card details can't be auto populated. Typically anything that slows down the user from paying gets fixed pretty quick. But you're right, browsers would have to become picky on saved credit card auto populate to force a change.
Earlier quoted context omitted.
3-D Secure was introduced in 2001. Additionally, I don't quite think making a payment is within the problem domain of OAuth. Most often I'm explicitly not trying to give the site access to my account - I'm trying to fulfil one request.
> I don't quite think making a payment is within the problem domain of OAuth OAuth is merely a way to authorize access. Depending on which scopes are requested, it could be a one-off request. Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. Furthermore OAuth would improve recurring payments - the website can request a max payment amount or frequency a…
No - access is assumed to last for a session. It is explicitly not one-off. "Offline access" allows the grantee to request new tokens without further input from the granter (via refresh tokens); it does not mean that access tokens can only be used once.
3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token.
> the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed.
I fail to see how this is a feature of OAuth specifically.
Earlier quoted context omitted.
I remember using a company-mandated pension website which required a very long password with a comprehensive selection of complexity requirements. To log in, the password had to be entered twice, but they had disabled the ability to use a password manager to populate them (I forget the exact mechanism). To me this is the worst of all worlds. If you put people off using your website, you are less likely to have breach…
My broker asks for 4-5 random letters of my password each time, making password managers unusable as well. Thinking about it now, how would you encrypt a password using this method? Create hashes of every combination?
Asking for random letters is a poor man's version of a zero knowledge proof. It's only marginally more secure than asking for the full password (if you want to break into an account you need to observe someone entering the password a few times instead of just once), at the cost of a very crappy user experience.
Earlier quoted context omitted.
> I don't quite think making a payment is within the problem domain of OAuth OAuth is merely a way to authorize access. Depending on which scopes are requested, it could be a one-off request. Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. Furthermore OAuth would improve recurring payments - the website can request a max payment amount or frequency a…
> Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. No - access is assumed to last for a session . It is explicitly not one-off. "Offline access" allows the grantee to request new tokens without further input from the granter (via refresh tokens); it does not mean that access tokens can only be used once. 3-D Secure already allows users to grant one-ti…
Through proper scoping the "session" can be boiled down to "this single payment request, for X merchant and Y amount", so not a problem in practice?
> 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token.
3D-Secure is terrible implementation, requiring the user to input potentially sensitive data into (what looks like) an iframe on a potentially untrusted webpage. There's no guarantee the 3D-Secure frame you see is real. OAuth in contrast relies on redirecting to your bank's website, so provided you check the domain and HTTPS is not compromised you can be guaranteed you're talking to your bank and not an impostor.
3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input. It's impossible to use on certain devices (TVs, etc) while OAuth supports alternative flows for exactly this purpose.
> I fail to see how this is a feature of OAuth specifically.
OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server, where as 3D-Secure authenticates the current transaction but otherwise you're still just handing over a card number and given the number is typically the same everywhere, the bank has no easy & reliable way to enforce per-merchant limits.
I see a lot of comments blaming either substack or 1password, but to me it seems the archaic transaction method of credit cards deserves most of the blame for these kinds of problems. If the transaction authentication takes place on a separate page hosted by your own bank (so after the amount has been finalised) these kinds of mistakes can't happen. Unless the user neglects to look at the shown amount, but then the u…
Earlier quoted context omitted.
Password managers aren't nearly intelligent enough to be used without copy and paste for sensitive forms. One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username. So…
> One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username. Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/mul…
Yes, but it’s my understanding that Chrome ignores this attribute because some website authors abuse it to disable autofill on the login pages because “security”. I’ve also seen some places disable pasting of a bank’s routing and account numbers because “security”. It’s actually more secure for me to copy-paste those numbers than type them because I can’t make a mistake then!
It’s a tough call because I hate when websites do that, but I also want them to be able to disable it in the right places for security.
I really wish Dashlane would let me disable the reminded to save my credit card details as this is a feature I do not care for
Earlier quoted context omitted.
What, is "password managers are insecure" really a thing?
Yes, if not explicitly then by their actions definitely. E.g.: there is only a single bank in France that hasn't switched to a stupid 6-8 digit system where you have to click buttons that appear in random order. Before then they often disabled autofill on passwords (luckily that could have been easily bypassed). They incessantly re-invent the wheel for 2-factor auth and so on. I find it very curious why banks of all…