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 of what to fill where because many sites don't set autocomplete properly, so inevitably it will guess wrongly sometimes.
Other examples are problems with lock files and file versioning (because programs tried to roll their own when the operating system didn't provide them), and the complexity of parsing "HTML soup" and emails with all kinds of bizarre invalid syntaxes.
I can't offer a general solution, but if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing. (Do Safari, Chrome and Edge already do this? Only they have the clout to make it happen.) The user could still fill out a text box lacking the standard autocomplete attribute by right-clicking and manually selecting the correct field. Password managers should also get cheaper because their vendors would not need armies of developers adding workarounds for popular sites.
Somehow this kind of nonsense has become culturally acceptable in the software industry. If the car industry worked this way you'd have to take your car back to the dealer once a month to be patched to take account of constantly changing fuel formulations. Standards exist for a reason.
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.
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 breaches - security through misery.
I wrote to them pointing out the issue and apparently it was put on their backlog for the following year. I think I received an update about it a couple of years later.
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 really need different passwords for every service, and then it doesn't really matter whether the server stores them in plaintext.
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.
> 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.)
Because the server doesn't store the password, only the "password hash" of the password. So if the server isn't compromised during the login there's no way for the attacker to learn the password itself.
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).
Though, my bank uses a dual-password setup where the first password is required in its entirety and a few letters of the second password are required. I suspect this is stored by using a (hopefully memory-hard) salted key derivation function/password hash function (such as Argon2 or scrypt) to derive an encryption key from the first password, which is then used to decrypt the second password.
At least, that's the way I'd design the system to minimize consequences of database compromise. Users are often not creative and often use related passwords. You'd want all of the stored information about the second password to provide clues to the first password only if the attacker had already cracked the first password. Hashing all of the permutations really blows up storage space and DB I/O.
Cryptographic literature often mentions one-way functions, but I don't think I've ever seen the phrase "one way encryption" in a cryptographic paper. It's not a phrase used by cryptographers, except rarely to describe encryption using trap door one-way functions such as RSA.
I think a lot of implementations don't do anything clever and just have a fixed set of combinations they use each time, so the number of stored hashes is smaller.
I thought about something similar to Shamir's Secret Sharing, polynomial fitting over a finite field, but in this case, information theory is working against you.
With Shamir's Secret Sharing, you start out with your secret expressed as a finite field element, and pick N-1 polynomial coefficients uniformly randomly from your finite field, and give M different participants values of the polynomial evaluated at different points. Information theory shows that having at most N-1 points on the polynomial still leaks no information about F(0). It's as secure as a one-time pad, and in the degenerate case of N=2 over a Galois field, is in fact a XOR-based one-time-pad. The amount of entropy added at generation time is greater than the amount of entropy in the secret.
In this partial password case, you'd want the "shared secret" to be a single value, and construct a polynomial such that, say 4 field elements, would always be sufficient to recover the same "secret". You're running the algorithm the wrong way, and unless you're forcing a password on the person, those letters are actually low-entropy instead of maximal entropy field points as in Shamir Secret Sharing.
I really don't see a way to use polynomial interpolation in this way without leaking entropy. I thought about using something similar to Schnorr threshold signatures[0] to solve the information leakage, but then you end up storing one elliptic curve public key per password letter, and the private key for each public key is a single letter, so trivial to bruit-force.
OnlyKey looks interesting. A few things make me skeptical though: It only supports 24 accounts, which is two orders of magnitude fewer than I have in my password manager. And the hardware design doesn't look super convenient or durable. I bought a YubiKey a few years ago, and kept in on my keychain, and before I had even used it a dozen times, the entire thing disintegrated and became unusable.
Edit: I'm also a bit uneasy about securing access to all by accounts by one single PIN that can be used to unlock a physical device that is easy for someone to steal unnoticed.
Yup. And they are, technically, because if someone has that one login and password, they can access all your accounts.
But it turns out that keeping that 1 login and password in your head and trusting the rest to your password service (especially if you let it make random passwords) is way more secure than what people do if they have to try to keep them all in their head.
So it's about relative security. Both sides are correct, in their narrow views of the situation.
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).
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 institutions are those with the worst security.
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.
> I can't offer a general solution, but if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing.
Unlikely. The password managers would just lose users.
I've even caught myself being annoyed at 1Password when it doesn't work while the cause is obviously the website doing some stupid thing.
I wonder how 1Password works on this problem though, do they just accept the crap and keep working on their guessing magic or do they also invest in standardization?
I always find it very interesting how the 1Password X (the standalone extension) team seems to work half the day just to fix some random website. At least their „fixed“ section of the release notes consists usually of a listing of websites where autofill does (did) not work [1].
One solution could be to very prominently highlight auto-filled fields especially if the standard auto-fill attributes are missing. That might at least help some users avoid submitting info they didn't intend to.
1Password does do something to help combat the problem that OP had... they change the background color of any input that they auto-filled to be blue. Blue is a weird color for most sites and it should stand out to the user (generally in a field of white) after they auto-fill a form. I have had 1Password fill in the wrong inputs before and only noticed it because of this feature. I noticed an input higher up on the checkout form had changed blue. It caught my attention and allowed me to fix it manually.
Now in this situation, it looks like Substack's UI is to blame. The secret form field appears to be heavily modified from its original form state, probably masking the blue background that 1Password attempted to give it.
1Password is in a difficult situation here. If the autofill doesn't work (because the developer of the website they are filling, uses non-standard naming), then users will blame 1Password for "not working", not their browser or the website developer. 1Password therefore has to make it work with as many forms as possible around the web, most of which are built by lazy developers trying to throw up a website during a hackathon, or from a developer that learned to code from a 1 hour youtube video. It's a tall order, from their perspective, to try to make this work with as many forms as possible, while having the fewest (ideally none) false positives.
The one thing I can recommend for anyone who uses any password manager, is that before you click submit on a form that you used auto-fill for, you always look over the entire form again. Now in OP's case, I could see how they could have easily missed the extra amount (again, Bad UI substack), but this is general rule that anyone with a password manager should follow. Double check everything before you submit.
> if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing
This is a market problem. All but the last password manager to do this would go out of business, due to reduced utility vs alternatives.
> Somehow this kind of nonsense has become culturally acceptable in the software industry.
This seems to be particularly common in the web development world, even in the fundamental tech upon which the web is built. Missing the closing tags in your HTML? The browser will just guess where it should be for you. Missing a semicolon in your Javascript? The interpreter will just guess where it should be for you. Invalid CSS? The browser will just silently ignore it. Illegal comments in your JSON? Most parsers will just assume you meant to ignore those lines.
I had a similar 1Password moment. I was buying airline tickets; entered my name, my wife’s name, address, declined insurance, declined hotel offer, scroll scroll scroll... Then I let 1Password fill in my payment details, which it did perfectly fine. But... what it ALSO did, on a field now well off the top of the screen, was change my wife’s first name to my full name.
I caught this when I got the confirmation email. I called the travel website, and they said since it was within 24 hours I could just cancel the tickets for free, or if I liked I could pay an outrageous fee to the airline to change the name on the ticket. Unsurprisingly I chose the former.
So, nor harm done, but if we’d gotten to the airport and my wife couldn’t come on holiday because I didn’t have a ticket for her... could have gone badly. :P
I had a similar story a few years ago, except it changed my birthdate rather than my name. Luckily I looked at the confirmation email for some reason and noticed it. Was a total nightmare to get that changed, although I didn't end up paying in the end.
A few years ago they wouldn’t let me board a flight from SFO to Australia because my visa said I was born in 1921 when my passport didn’t agree. After a good bit of hassle we just had me go and apply for (and pay for) another visa on the electronic application site and this time I noticed that it’s exactly what happened: 1Password (IIRC) used my Visa expiration year for my visa birthday.
I’m lucky that my status meant it was an automatic approval for the second visa!
It's amazing though that they literally gave a visa to some other random person without any issue at all (i.e. not even cross-checking some values in your passport).
> But... what it ALSO did, on a field now well off the top of the screen, was change my wife’s first name to my full name.
I also had a similar experience yesterday, with less expensive purchases fortunately.
The default behavior of 1Password auto-fill is wrong IMO. It should only fill fields after the field that currently has the focus. Not start filling whatever is available from the top of the page.
I had the opposite experience a few years ago: I was a new user of password managers and did not let mine autofill when booking my plane.
The air carrier form was not consistent with my country's name nomenclature: First, Middle, Last instead of First (+second and third) and Last name. I filled it wrongly and had to pay $40 at the check-in counter because there was no passenger registered to my name on the flight.
Tried again with my password manager (Dashlane) a few days later and realized that I should have trusted it. Also, I know that it only fills fields after the selected one, not those before.
I've put "temporarily" in the title because the post now says the money has been refunded. The article is worth leaving up because, unlike the typical riler-upper, it touches on a phenomenon which is interesting in its own right. But I don't think it's fair to leave up a title that implies that there's an uncorrected injustice to get angry about. If anyone has a better solution, we can do that instead.
hi dang, I propose a universal solution for similar instances like when a site was down or when another issue has been sorted out: the use of "[resolved]" appended to the title.
This will save you any future issues of having to find ways to reword a title to indicate an issue has been resolved while also allowing for a way for anyone who wants to analyse resolved problems an easy [resolved] tag to filter for.
I hope you don't mind this suggestion if it's feasible to standardise.
Yikes. I love my password manager, but I decided when I got it that I was never going to use the browser extensions. Putting your password manager anywhere near your web browser just seems like insanity to me (all the exploit write-ups I recall about password managers were related to browser extensions and sandbox escapes).
This seems like another reason. It's not worth it. Keep the password manager in its own app and apply the tiny extra effort of pasting the password from there.
To counter this: if you happen to find yourself on the phishing domain facebo0k.com and you end up copying your password into that.. Browser extensions guard for this better than we can.
That's something to think about. But I'm not sure how I would end up on fak3b00k.com unless something changed my bookmark for it, or I really mistyped it but if I did that the URL being different is a dead giveaway.
Some password managers will type the username/password into the browser (through a virtual keyboard I think), not copy-paste them to protect against clipboard attacks. Eg. Keepasssc
There are non-browser-extension password managers that still emulate you typing on your keyboard, rather than going through clipboard.
Personally I use rofi-pass to access GNU pass passwords (so just a hotkey and search for password name)
I'd warmly recommend it (or whatever other client you use for GNU pass) but I'm sure you can find similar functionality for any other decent password manager.
I a simple algorithm to generate a password based on the name of the service you are using, interleaved with a constant master password you remember. You can do the same thing with a password-manager password + clipboard, interleaved with a constant master password you remember, which should be even better.
I don't think a webpage can read clipboard without the user manually pasting.
If there's some malicious desktop program running on your machine at the same time as the password manager then you're probably screwed regardless of whether the password passes through the clipboard - but maybe there's some subtleties I'm missing here.
Between Keepass, 1passwword, and lastpass I've never seen a password manager that just shows the password without the user explicitly choosing to reveal it
1password has the option to do so and I do it on my home desktop computer. Obviously on mobile devices it would be a bad idea and on those I leave that option in it's default, disabled state :)
Maybe we should take the best of both worlds then: an extension that only knows which domains you have passwords saved for, but not the account or PW. It just serves as a red flag if the domain is suspect.
This is how the Keepass Helper extension has worked for years: putting the domain in the RHS of the titlebar. Then with autotype set to match that you can autotype from the global hotkey. Keepass 2 can even split the credentials between key presses and pasting.
There are other URL in title extensions for most browsers. And they're simple enough you can audit them or write your own.
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 imagine a form like this:
Amount to transfer: <input type="number">
From account ID: <input type="text">
Confirm password: <input type="password">
<button type="submit">Submit</button>
I found that there's no good hackless way to allow a password manager to autofill the password without touching the other fields with a username or some other quirk like just clearing your inputs. Even a fix like opening a modal with the lone password confirmation field doesn't necessarily fix it in all browser/OS configurations.
Password managers are braindead and browsers don't give you any tools to help.
> 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.
Nice note. One problem is that you are left without options, only hacks, to work around this heavy handed behavior. It wouldn't be so bad if you could opt-out with autocomplete="off".
And even if it did work, a spec is always underspecified even for the password manager who wants to follow it 1:1, so even in a best case scenario, you don't have implementation consensus. For example, you would think password manager heuristics wouldn't look outside the current <form> to assume the username field, but some do on some browsers.
The end result is that if you have a need that isn't the general case, you end up having to trade away UX to cater to software.
> Note that this behavior is defined as part of the `autocomplete` standard.
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.
Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities.
Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away
The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus.
This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA.
How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care.
Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.
1Password was one of my test extensions and the one I use every day. It works most of the time because username/password combos are the most common autofill configurations.
So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example.
They just don't handle anything other than the main case very well.
Interesting. The weirdest site I use on a regular basis is Mailgun and it has this scrolling form which isolates entry for email/password/2fa (which, as an aside, I hate) and it gets it right every time. I can't remember any instances of it going wrong, actually.
You can still use something like passmenu[0] bundled with GNU pass, bind it to a hotkey and it fills it in as if you were typing on your keyboard, no clipboard involved.
Lastpass used to have an option for autofill to only fill empty fields, not sure if it is still there as I moved on a year ago but it stopped a little of that annoyance.
After learning about how every app in your PC has unfettered un monitored access to the clipboard why in gods name would you do that? I explicitly make a point to never copy any password to the clipboard!
I'm still utterly perplexed about why every major operating system handles the clipboard this way. It's such an obvious privacy issue, and the fix seems really simple: only allow clipboard access when the user explicitly grants access through a system-provided user interface (whether that be a dialogue box, menu item or keyboard shortcut)
Apple's iOS 14 uses the half-solution of notifying the user after an application has read the clipboard. But at that point the end user is already a step behind the attacker, and mitigations may no longer be possible. Nevermind that this solution is dependant on the user noticing and understanding the implications of the clipboard access notification (the novice user is likely oblivious to the security risks)
On a desktop, you can use KeePass and its variants to "auto-type". It'll switch focus to the last app you were in and type your username, a tab, your password, and then enter. No extensions or clipboard required. Just hit CTRL-SHIFT-V after highlighting the entry.
I tried using this but the final "enter" made me too uncomfortable. I really wish it was optional so I could verify where it just typed the password before submitting. After accidentally sending my password in the wrong field/window a couple of times I stopped using it entirely. Now I just copy-paste :(
keepassxc has extra options in the auto-type menu for "username", "username<enter>", "password" and "password<enter>" in addition to the normal "username<tab>password<enter>"
It looks like paste and it's almost the same from the user perspective, but the data never makes it to the clipboard, where it would be available to every running application.
That's a different option (CTRL-C). You can copy and paste the username and password. There's a default clearing timeout that's more to ensure the user doesn't accidentally paste it elsewhere. The auto-type option I mentioned is different.
Use a browser extension. For example, the 1Password extension uses (authenticated) IPC to talk to the app and then injects the password into the DOM directly.
Gfycat already generates memorable URLs so it’s definitely possible. I myself do it manually nowadays (ie generate phrase password to be stored in manager so I can copy it manually if needed)
There is no way I could have convinced the people I have to use a password manager without the browser extension. So for those people it was either same password on all sites or a password manager with a browser extension.
I've never encountered any autofill instance where the effects of autofill wasn't immediately apparent (usually it's just the username and password). Having a special hidden fields in your form seems like a Bad Idea, but what is worrying is that there is nothing stopping more devs from implementing something like this. The only reason why we don't see it more often is probably because it takes more effort to make a "smart" form like this.
I use Firefox's own password manager (https://www.mozilla.org/en-US/firefox/lockwise/) inbuilt into the browser. I think it's a better compromise than having to expose sensitive credentials into my clipboard. IT works across devices too, so there's no copy pasting on my Android device which god forbid is probably reading my clipboard too (I know Facebook used to do that).
I do not see a reason to copy paste in any use case at all.
this is why I use a password manager that has no network connectivity whatsoever, and no browser integration. keepassx with a v2.0 keepass format file.
it works from a local file on disk. yes, it's more inconvenient if I am away from the computer it lives on, and I need to update a password, I have to connect the VPN to my home office, ssh to it, and run 'kpcli' (a keepass format command line program), or run keepassx in a vnc-over-ssh session.
3. The app makes the text box into a button plus text box. As a button, it modifies its parent widget, the radio button. This is unexpected behavior. The app would be better to show the text box after the user selects the "Founding Member" radio button. That would make the text box subordinate to the radio button and reduce user errors. See
"8 Design Guidelines for Complex Applications - 6. Reduce Clutter Without Reducing Capability" https://www.nngroup.com/articles/complex-application-design/
I wish sites would test their forms with popular password management systems. This kind of thing happens all too often (thought perhaps not with such a high cost). Why not make it easy for people who auto-fill with these programs -- don't fight them.
(And I won't get into sites that won't let you paste passwords into their forms.)
Whats the solution for the busy engineer? Anyone know a Selenium plug in that let's you run with browser extensions or something? There's too many popular extensions to test manually.
Haven't seen this automated, but I have seen internal issues raised by folks within large orgs when their extension started breaking things. But it's only once you have 50+ to 100's of engineers working on a product, each with a subset of extensions installed, that you can rely on the cross product of engineers and their installed extensions for realistic coverage.
I mean what is there to test, really? Just use the the different input types and mark your fields as "email", "password" and so on. There is nothing to test really.
If a password manager does not work when given clear hints / type description of what is expected, then that is the fault of the password manager.
This is (generally) done because they offer SSO functionality, and need to know whether to redirect the user to their corporate SSO page or show the password prompt.
The problem is that all of these autofillers are already way too complex, because almost no one uses the optimal markup (adding the attribute autocomplete="cc-exp-year", in this case)—almost no one has even heard of the proper autocomplete markup here (I remember being in a conference room with two or three hundred other web developers a couple of years back, and the speaker asked who knew about autocomplete="new-password" and the likes; only three of us raised our hands: I and my coworker, and one other).
They’re already complex enough that it’s a disaster trying to figure anything out. You say it wouldn’t be difficult to catch this, but either it’ll be a special case finely tuned for this particular site, or it’ll break another site, causing expiry year to no longer be filled out where previously it was and should be.
I wonder how many of those devs use a password manager and just thought it was magic they didn't need to worry about when they were writing those kinds of forms.
I assumed that kind of markup had to exist, but its not my job to do web development at all, so time being finite, I'd never seen those. But I always assumed that they'd have to exist if I ever went looking. Why do people whose job it is to know these things not bother checking?
The problem is there are too many standards and they are all clutered on too many websites. I mean there should be a website listing the standard in an easy way.
Just wanted to add some detail on how the 1Password extension operates here, since the term "autofill" can be ambiguous:
1. The "autofill" function only fills in the credit number when the user specifically tells it to; it does not proactively fill forms with no user intervention.
2. "autofill" does not automatically submit the form after filling (although certain forms may be implemented to submit automatically once complete); in this particular case, the user still has a chance to review the completed form before manually clicking the subscribe button.
All of this isn't particularly relevant if the function is abysmally terrible at filling the correct fields with the correct data, which in the case of 1Password certainly seems to be the case.
In the example posted here, it happily completed fields for the credit card expiration year TWICE on the same form, one of which was pre-populated with a value that could not possibly have been a year. The apparent cause is because the substring 'year' appeared in the field name. Levenshtein distance of 12 for a 4 letter word? Yep, looks good! I mean, it's a result so certain there's no need to prompt the user, highlight changed fields or anything, right?
This is exactly why I don't trust autofill. How many times has it passed along information you didn't intend, but without any obvious errors? Nobody knows.
Similar situation here. I use 1Password every day, but I only trust it to autofill simple login forms. Where something more complex is happening, I tend to copy information over field by field.
This was trained into me over the years as I saw 1Password do too many things that were wrong or even sometimes scary. The nominal benefit you get sometimes when it works properly isn't worth it.
And yes, web providers should give their web forms better names and better semantic information (e.g. `<input type="email">`), but even in 2021 it's just not always the case.
> And yes, web providers should give their web forms better names and better semantic information (e.g. `<input type="email">`), but even in 2021 it's just not always the case.
Well, there's no semantic input for "year" or "currency", so there's nothing the form designer could do to stop 1Password from picking the wrong field. This does kinda get to the root of the issue, which is that 1Password has to do a lot of "cognitive" analysis of the page to find the forms it wants which is simultaneously why it does better than most autofillers, and has worse false positives than most autofillers.
I am also a happy 1Password user, and I'll happily let it prefill a complex form for me, but I've caught enough of its mistakes in the past that I will always manually double check before submitting. I could also see myself making a similar mistake as this user on this form though (since it's so simple I might not manually double check).
> Well, there's no semantic input for "year" or "currency", so there's nothing the form designer could do to stop 1Password from picking the wrong field.
This is how you mark up the expiry year in a credit card form:
Mock me if you wish, but I tend to use 1Password for what it does best but use Apple’s Autofill for credit cards. It misses stuff sometimes but -fingers crossed - no issues with mis population into amount fields. I also use ApplePay or PayPal wherever possible to avoid data entry and reduce friction.
Autofill is a hot mess. If you have more than one address, and also occasionally fill up info for your partner, or with your work phone, things can really escalate. I think my Chrome has 20 different combinations of 2 names, 2 addresses, 2 phone numbers.
And auto-fill always insists to fill out fields that have already been filled in - why can´t it just allow completion of a single form field, instead of putting in random information in all other fields. Before auto-fill, the fill-in suggestions for a single field actually used to be useful: start typing three letters and select the auto-suggested value.
Now, every time I fill out a form I use the autofill suggestions as a way to remember the information that needs to be filled in. But I have to watch out like a hawk to not actually let it "fill" that exact phone number I`m typing in, otherwise it'll fuck up the whole form and force me to start over.
Exactly. This is also the reason why developers don't want autocomplete - the data is so much lower quality.
So developers started by breaking browser autocomplete, to which browsers responded by ignoring developer preferences, to which developers respond with different tricks...
If it's not 1Password's fault, who's is it? Obviously this story had a happy ending, so it's not a terribly big issue, but 1Password's client ultimately passed along the unwanted data.
Speaking from personal experience -- over about six years at this point -- there are many, many web sites on the internets that 1Password's autofill works perfectly well on, and many others where it doesn't work perfectly but fails gracefully (or at least non-destructively). "Here is one site where it makes a mistake that could be catastrophic if you don't catch it" is just not a slam-dunk proof of 1Password being "poorly designed."
It is a visible input field styled not to look like an input field until that radio button is selected, but it is not "hidden" in the HTML sense. It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
> It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
How is it not a shortcoming? Any human looking at the page can immediately tell that this form field should not be autofilled.
Difficult problem to solve? Sure, doesn't make it any less of a shortcoming.
That exactly correct, which is why the fault is with 1Password's fill mechanism.
A product has a bug when it does not produce output in-line with its stated purpose and process. Nobody would use a refrigerator that suddenly forgets to keep food cold when a carton of milk is placed on the shelf.
So you want 1Password to check CSS of the form before auto filling? The form itself isn’t hidden it’s styled to be flat. That’s the biggest problem of it.
The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd.
The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app.
This is already possible in Portugal with an app where you can give a seller your phone number and it prompts you for payment.
(might be something of a privacy issue, but it beats a possible fraud issue)
Poland has a neat system - you input one time code into the sellers payment processor, and then you get to confirm the payment in your app.
Code is one time use, valid for 2 minutes - and you can see all the details in the confirmation that comes from your banking app.
you can also use the same system to tie your phone number to your bank acc, letting other people in this system send you money instantly without extra fees between different banks - and you only need to share your phone number.
Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid.
We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).
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 and the user (on their bank's authentication page) can further constrain those settings if needed.
> 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-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.
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.
> 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.
That is an implementation detail - OAuth itself works on the basis of web URLs so it's absolutely possible to open the login URLs in the default browser instead of in a web view.
That's one of the reasons I don't want to use 1Password and instead I'm just using old KeePass. KeePass fills what field I've selected. 1Password does its own magic and I don't like magic. KeePass might be slower, but I'm not filling those forms every day, so I can live with it. Basically KeePass does simple thing and does it well. 1Password might be good at doing complex things, but it does not have AI.
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 user is clearly at fault.
This is the way it happens in India. We have to enter an OTP to authenticate the transaction. The OTP comes as a SMS and it tells the amount.Some merchants tie up with bank and we can enter the OTP on the merchant's site or choose to go to the bank's site to enter OTP. In any case the OTP page is a new page and the amount is displayed.
I'd say the Substack UI is messed up if (a) there's a hidden input box that automatically changes the selection, even though the user cannot manually enter information there, and (b) there's no confirmation screen to confirm everything is correct. It shouldn't matter that a password manager exposed the problem.
The use of the word "hidden" in the article is misleading. The field is visible and editable by the user -- it is just styled in a way that does not make it clear it is an editable field. There is a GIF in the article showing the author changing this field value manually.
It's not misleading at all; it's an input with the type set to "hidden". The field doesn't become visible until you select the radio button for that subscription level.
Yeah it seems pretty clear that this was a 1Password flaw and didn't really have anything to do with Substack's UI. And yes, the first paragraph notes that no money was spent, so not really sure why multiple people have downvoted your comment.
If your UI can charge me $2023 instead of $250 without so much of a confirmation, your UI is just a minefield. Forget about auto fill, humans make typos in a free entry text box.
Many many years ago I once made a $6900 payment on a $69 internet bill because of a misplaced decimal point, with no confirmation before the amount was debited from my bank account. Definitely partly my fault for missing it, but they also didn’t design that payment flow to stop it from happening or even to autofill the correct payment amount.
(I was super unlucky that it happened when I’d just received a big performance bonus, or the bank would have simply declined the transaction outright due to me not having anything remotely like that much money in my accounts)
It took a surprising number of customer service calls (and then weeks) to get that payment refunded. And more than once I had to explain to a service rep that no, I didn’t want to just leave my internet service account balance thousands of dollars in credit so I wouldn’t need to pay the monthly bill for the next decade. I mean, obviously.
In Germany, when paying at a restaurant, the machine often asks you to type the tip you want, before your card PIN. The (badly lit) screen also tells that to the user in German, which doesn't help if you don't speak it.
It has happened quite often that I typed my PIN by habit and the machine just refused a tip amount that large, thankfully.
From the user (donator)'s point of view, a confirmation is a good thing. From their point of view, asking someone to confirm if they really want to donate X is a chance to lose legitimately-entered X's.
And obviously from their point of view, OP actually entered $ 2023 and was fully aware of what he was doing (they didn't know about the bug)
If your business’s success depends on charging people money they’ll regret spending once they see a payment confirmation one second later, you should find a new business idea asap.
> Yeah it seems pretty clear that this was a 1Password flaw and didn't really have anything to do with Substack's UI
The UI is styled to make it so that a form input is completely indistinguishable from surrounding text, to such an extent that even people who know it's a form input in this thread have incorrectly assumed that it's not manually editable.
I can't comprehend how anyone could defend deliberately misleading UI design in a form that is asking for your credit card information. This is a problem with Substack. 1Password can definitely do better to guard against it happening, but the only reason it did happen is because Substack actively tried to hide important information from users in a payment screen.
I think the end of the article clearly admits that it's a little bit of both and actually gives really good advice to keep in mind while designing checkout flows.
If all the password managers in the world fail at this site, it's still a problem with the password managers. The fact that the field was looking as non-editable from the start has nothing to do with the fact that it filled the wrong field.
The user also had a chance to see how it filled the form and didn't bother checking.
I agree, this is awful (I'd really like to know how on earth it decided that this field is where the expiration year belongs. It sounds like some extremely aggressive assumptions are being made).
>The user also had a chance to see how it filled the form and didn't bother checking.
It's impossible to overstate how wrongheaded, unproductive, and, frankly, lazy this sentiment is.
Probably not fair to pin it fully on 1pw or substack.
1PW autofills based on common cc form names, year, credit_card[year] etc etc. Substack clearly named the field a name that could hit that, probably amount_per_year.
1PW can't account for every form on every website, just not realistic.
How's the headline not true? It's a UI/UX issue that caused him to be charged that amount?
Looking at the source of the actual page, it's very odd markup.
There's a real input field, and a hidden input field "on top of" each other. I guess one is the stylized user-interactive one of which the value gets normalized into cents into the hidden one?
I've updated my blog post to include 1Password in the title as it contributed to the issue (I can't update the title here). That said, I've never experienced this before, having used 1Password on 100s of other payment forms so something is up.
I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.
1password payment form filling works fine so rarely for me, I usually copy just number by hand. I wonder if that's somehow specific to Russia (field names are still in english, but it doesn't seem to help much)
Maybe it's the same subscriber and/or same publisher as in this blog post? If not, that would either be a very unhappy coincidence or a strong signal to Substack that they need to fix this issue.
I see replies blaming 1password being downvoted, so I'll ask a question instead. Why would 1password decide to fill out that particular input with the expiration date?
Because that one input had the word "year" in it. 1password confused "expiration year" for "$ / year".
It's a good bug.
Both substack and 1password are responsible to some degree, and it will be figured out, though I think 1password has more obligation to take action because it can happen with other websites too.
Just because a lot of people are commenting on this without seeing the form, if you go here[1] you can see it in action (no association with the page, it was the first one that turned up on Google).
A couple of takeaways missed by various comments:
The hidden input box can in fact be manually edited, and if the user selects "Founding member" that fact is highlighted (the cursor is inserted into the textbox).
The hidden input's name attribute is "value". The guess that 1Password is basing its guess on the "/year" text is probably accurate.
The 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)
It was not expensive, merely inconvenient, but 1Password and Waze combined to give me a two hours of frustration in December. At the end I went back to the beginning and reported the experience here. I wrote on twitter,
"Let's follow a trail of really Bad Tech Decisions between Waze and 1Password."
Interesting bug. Appreciate the post and the disclaimer at the top but IMO the headline should be updated too. Right now it’s a bit clickbaity and also inaccurate.
This story reminded me of my experiences working in a bar (in the UK, chip-and-pin was a thing but contactless was only just rolling out) It was mainly a student bar so basically every card was a debit card...
I occasionally would come across declined card receipts from the machine for some 6 figure amount that had been attempted to charge. Was concerned at first but what had happened was clearly the staff member had forgotten to press enter after typing in the amount, the customer still saw the amount - put in their pin, enter, now it says type pin, try again, then panic when their bank declines it. Luckily the only bad thing that would come out of this is that they should go to the ATM and change the pin, after running the transaction again properly.
You don't get cash back bonuses with a pre-paid card. In fact, they cost money. I am not going to give up saving 3% on everything I buy just to avoid this rare error that was easily corrected for no lost money.
Presumably on a credit card, which would also have more robust chargeback rights than debit cards typically do. Between that and the likely relatively high value of a customer qualifying for 3% cash back on every transaction, I doubt it'd be more than a minor inconvenience to have the transaction reversed, even if the acquirer declined to refund it - which didn't happen here, in any case.
You can get a "refund" everywhere, because it's an unauthorized transaction. If the merchant will not refund, you simply call up the card company and explain how you agreed to a charge of $10 and were subsequently charged $2,000. The only reason the article was phrased as "costing" the author money is for clickbait.
My bank set up a free sub-account with its own debit card that I use exclusively for online transactions.
I keep a small amount of cash in it at any time, and then do an instant transfer from my main account as needed for larger purchases. If that CC# were to get hacked, it would be annoying but not catastrophic.
Inconvenience level is pretty minimal and it’s served me pretty well.
You are lucky. I was trying to get a refund from fax site where they let you enter a value into dropdown and then happily charge you default value.
I tried to dispute it with them, tried to dispute with Paypal and itdidn't protected me, even if I had evidence in a way of showing how the UI is not working and the charge - the answer was always "not enough documents provided". Luckily it was only $10, but maybe I should also have posted on HN
It's interesting Substack is getting the blame here rather than 1Password.
Ultimately, though, I think it's two separate systems doing the best they can to work together, and failing. Payments should be handled by the browser, like how mobile phones do it. I loathe giving Google or Apple more power/control, but this is a situation where I'm still genuinely shocked how rudimentary payments online are.
Ironically, the founder of my company and I spent over an hour breaking apart this exact page yesterday talking about its UI. There are a lot of really good things that this page does right (shows tradeoffs between different tiers in a way that's not confusing at every tier), but... yikes. Sorry to hear about this.
One of my utilities likes to add an extra bit of login confirmation with a question, like, "What is your favorite sport's team?". Every time, my password manager prompts me to overwrite my site password with answers to those questions.
It's like walking over a railroad bridge that's falling apart.
It's been a while, but a similar thing happened to me. The delivery address form was on the same page as the cart, and my autofill put my zip code into the article amount. A little shocking at first to see a bill of 65,000€ instead of 12€, but at least it took less than an hour to resolve.
Great to hear that this got resolved and fair play to Substack for that, but this is inarguably a 1Password bug. If there had been any issue with resolution, they'd be the party I'd be chasing.
Other commenters here have bemoaned the need for these kind of heuristics in dealing with compat with bad HTML form implementations, but there's an easy fix to that: origin-based compat lists. Browsers do this for quirksmode/website compat fixes: they apply heuristics to a specifically tested list of sites. And browsers need to work with a much larger set of webpages than 1Password, so there's no reason 1Password couldn't do the same.
There isn't really any good excuse for applying heuristics blindly by default to a wide range of websites you have not tested those heuristics against. There might be an argument if it increased overall compat with the web IF these weren't highly sensitive pages (1Password saves credit card details!), but in this case there isn't really any excuse. The cost of achieving "blind" compat with smaller sites is too high in this case.
That was my first thought, where's the server-side validation that the amount submitted is in-line with what the UI showed. In this case it was higher than the UI stated, but what happens if it was lower...
1Pass definitely needs to add some kind of notice or alert when it fills in hidden fields. And it really needs to not overwrite a field that’s already been filled in. It’s really frustrating when it decides to h do everything you typed in.
Whoa. That's absolutely insane. And yet now that someone has demonstrated it I can see this turning into a dark pattern that a variety of less scrupulous sites will use in the foreseeable future.
Why are those fields not overridden in the backend?... If the back-end doesn't check those fields are what they should be for each option then the reverse could also be true (free membership)
What do you mean? The goal of that subscription option is to allow the user to pay a custom amount. I guarantee you the custom amount cannot be less than the yearly membership.
I only let my password manager fill in passwords. It’s less efficient for sure but my cc details are in muscle memory and filling out my name and address doesn’t really bother me too much.
It’s not “hidden” in the HTML form sense. It’s an input that is not styled as an obvious input field. The idea here is that if you want to, you can give the author more money as a “founding member”. You can the set the amount you’d like to give.
It is visible to the user, but it isn’t obvious that this is an adjustable value at all (at least on mobile). There are a number of UX issues at play here... but a poorly styled input isn’t an excuse for the password manager.
That hidden input element contains the normalized value in cents, if that got filled out he would have only gotten charged $20. Right before it in the DOM is the stylized user-input field which does not get hidden (and populates the hidden field via JS)
OSs need to provide credential management with APIs to let users choose their password manager, and then browsers can use OS support. Only then can we stop the madness.
Nevermind that, does that mean that their billing has an exploit and I can buy Substack Founder for $1? Or can I convince their system to bill me -$1 for that matter.
It can't login to other applications, such as steam and discord clients.
It can't create passwords based on random words. If for some reason I can't use the password manager directly, I Can quickly check that the password is staples-horse-battery-correct and type it manually.
(I'm a Firefox user using keepassXC, but it's basically the same situation)
You can store any number of fields, rather than just 1 username and password per website.
I typically have notes, maybe one-time passwords, a PIN, the email I signed up with, whether they have my address, various URL if they share the login, etc.
What if I want to use another browser? What if I want to use the same password on my iPhone? What if I manage a team and need to share certain passwords with my teammates?
Every single other website I've purchased from has a "confirm your order" page. Instantly charging the customer's card after submitting the payment form is a headache for both customers and merchants, because it's easy to make mistakes.
I think it's both. 1Password shouldn't have filled in that amount and Substack should have had a clear confirmation - "Are you sure you want to pay *2,023 dollars* a year?"
The author knew from the beginning it wouldn't "cost them $2023", but that it would most likely be solved by a simple support request. The title is misleading.
Other examples are problems with lock files and file versioning (because programs tried to roll their own when the operating system didn't provide them), and the complexity of parsing "HTML soup" and emails with all kinds of bizarre invalid syntaxes.
I can't offer a general solution, but if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing. (Do Safari, Chrome and Edge already do this? Only they have the clout to make it happen.) The user could still fill out a text box lacking the standard autocomplete attribute by right-clicking and manually selecting the correct field. Password managers should also get cheaper because their vendors would not need armies of developers adding workarounds for popular sites.
Somehow this kind of nonsense has become culturally acceptable in the software industry. If the car industry worked this way you'd have to take your car back to the dealer once a month to be patched to take account of constantly changing fuel formulations. Standards exist for a reason.