It may not convert as well, but this is why I really appreciate the payment confirmation type screen before the charge is actually made.
Substack's UI and 1Password temporarily cost me $2k
231–240 of 278 posts
Re: Substack's UI and 1Password temporarily cost me $2k
#232Earlier quoted context omitted.
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.
Yeah but people that use password managers are TINY fraction of users.
oh yeah after reading the OP i totally wonder why
Re: Substack's UI and 1Password temporarily cost me $2k
#233Earlier quoted context omitted.
> 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…
> access is assumed to last for a session 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 lik…
> 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?
Why do we need to switch from a system that already meets the requirement to one that needs to be limited via implementation to achieve the same thing?
> 3D-Secure is terrible implementation...3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input.
I see the problem here - you are conflating protocol with implementation. Nothing about the 3-D Secure protocol requires an iframe, a sketchy webpage, or entering a password (much like nothing about the OAuth protocol requires that the provider uses the same domain they use for day-to-day operations to handle auth requests) - in fact, 3DS2 supports out-of-band authentication.
If a protocol has flaws, that's typically a call to update the protocol (as OAuth itself was updated from 1.0 to 2.0, and as 3-D Secure has been). It's usually not a call to switch to a different protocol that's not actually made for the use case in question and needs to be stretched to fit. Again, the problem of transaction approval is explicitly not one of access delegation (and not every security problem can be framed as one of access delegation).
> OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server...the bank has no easy & reliable way to enforce per-merchant limits.
Much more information than just the card number is passed along when you make a transaction using a card, including information used for things like risk assessment and rewards programs.
Maybe this is a cultural difference, but it's simply absurd to me that one could think that their bank of all entities has no insight into their card transactions. That there's no trendily designed UI on a system/dataset does not mean it does not exist.
Re: Substack's UI and 1Password temporarily cost me $2k
#234Earlier quoted context omitted.
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?
You wouldn't encrypt/hash it, since 4-5 letters (say 30 bits) is trivial to brute force anyway. Talking about offline password encryption/hashing is a bit of a red herring anyway, since it distracts from the fact that you're still sending your full password to the server for verification each time, so if the server is compromised for any length of time your password will be as well. Reusing passwords is broken: you r…
A lot of these sites will even change the letters they ask for every time you reload the page. So the number of observations is probably less than 10. Maybe 1 if you have access to decent chunk of IPs (assuming they will block you if you reload the page too many times).
Re: Substack's UI and 1Password temporarily cost me $2k
#235Earlier 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.
I used to use Keepass with auto-type. I had a hotkey for it, and it would recognize the site based on the browser window title.
That would probably be the best of both, no clipboard, and no browser addons.
Re: Substack's UI and 1Password temporarily cost me $2k
#236Earlier quoted context omitted.
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.
Yeah but people that use password managers are TINY fraction of users.
All modern browsers now ship with a password manager (Firefox is currently rolling out CC filling country-by-country) so that number can't be too low.
Re: Substack's UI and 1Password temporarily cost me $2k
#237This is why I don't have my credit cards stored for "easy" input and submission and instead always enter them manually 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
Also, after I finished entering it, I hit Ctrl-F and manually enter it again in the search popup to see if it matches what I typed into the field.
Re: Substack's UI and 1Password temporarily cost me $2k
#238Earlier 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.
What, is "password managers are insecure" really a thing?
It can be. Single master password, if leaked or otherwise getting into the wrong hands, gives access to all your auth details. This is part of why I keep to a desktop based password manager rather than an online one.
But it depends on your threat model and attack surface area/shape. A strong password on a post-it on your monitor is stupidly insecure locally, but far more than just having a weak password if you consider only non-local (to the user) attacks (neither that site hacker in far-off Hackyoustan nor his pet bots can see the post-it, but could try brute force a short easy to remember password).
Re: Substack's UI and 1Password temporarily cost me $2k
#239The deeper problem here is that credit card numbers are obsolete. Websites should be using Apple Pay and similar stored payment info APIs that don't go through an unnecessary error-prone user-facing interface. (Yes, Apple etc. are oligopolists, but so are Visa/MasterCard)
Re: Substack's UI and 1Password temporarily cost me $2k
#240Earlier quoted context omitted.
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?
You wouldn't encrypt/hash it, since 4-5 letters (say 30 bits) is trivial to brute force anyway. Talking about offline password encryption/hashing is a bit of a red herring anyway, since it distracts from the fact that you're still sending your full password to the server for verification each time, so if the server is compromised for any length of time your password will be as well. Reusing passwords is broken: you r…
> you're still sending your full password to the server for verification each time, so if the server is compromised for any length of time your password will be as well.
The key difference between storing plaintext passwords and hashed passwords is that with hashed passwords, you can only compromise users who log in during the interval when the system is compromised, and even then, only for worse compromises (eg if all the attacker gets is arbitrary disk read, compromising hashed passwords would be impossible in most scenarios.)