Substack's UI and 1Password temporarily cost me $2k(timmyomahony.com) |
Substack's UI and 1Password temporarily cost me $2k(timmyomahony.com) |
Also he was able to get a refund, and i think in most places online, you can cancel the order
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.
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
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.
It's like walking over a railroad bridge that's falling apart.
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.
I'm happy to use for storing my passwords and maybe logging in but that's about it.
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.
<input name="amount" type="hidden" value="15000">
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)
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.
<input class="variable-amount-input" type="text" style="width: 27px;">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 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.
But you're right, browsers would have to become picky on saved credit card auto populate to force a change.
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?
Hopefully hardware tokens can help us get rid of passwords soon.
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.
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.
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 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’m lucky that my status meant it was an automatic approval for the second visa!
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.
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.
Edit 3 weeks later: I used that on https://news.ycombinator.com/item?id=26815768. Hopefully will continue to remember.
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.
1. It uses placeholder text instead of a label. See "Placeholders in Form Fields Are Harmful" https://www.nngroup.com/articles/form-design-placeholders/
2. It hides the fact that the "$250/year" is actually a text box. See "Long-Term Exposure to Flat Design: How the Trend Slowly Decreases User Efficiency" https://www.nngroup.com/articles/flat-design-long-exposure/
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/
(And I won't get into sites that won't let you paste passwords into their forms.)
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.
I don’t see how they benefit real users in any way, and my password manager can’t understand it, requiring manual copy/paste entry
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.
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?
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)
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.
This is something I only encounter with American companies/sites/processors. When I shop or pay online locally, 3-D Secure is always required.
It's kinda appalling how much of the web/online experience is negatively impacted by US norms.
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.
Validating in some other application) website seems reasonable to me.
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.
I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.
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.
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.
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.
I think the problem is precisely that very last character, the "s". How many such APIs should "websites" be using?
https://news.ycombinator.com/item?id=13329525
For this reason, never use auto form fill.
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
Did 1Password fill in the year twice? That would be a huge bug. Or will a fraud detection system ignore the missing year if everything else is fine?
"Let's follow a trail of really Bad Tech Decisions between Waze and 1Password."
-- https://twitter.com/cpp_delphi_dave/status/13356390392953036... to read more. It's short.
Of the two, 1Password did reach out, but Support emails went nowhere. Waze never reached out at all.
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.
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.
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>
Password managers are braindead and browsers don't give you any tools to help.
Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastr...
> an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state
> New autofill field name: "username"
The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.
[0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...
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)
I do not see a reason to copy paste in any use case at all.
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.
but that hassle is worth it in my opinion.
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.
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.
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).
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.
So developers started by breaking browser autocomplete, to which browsers responded by ignoring developer preferences, to which developers respond with different tricks...
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.
and it would probably also fail with tab.
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?
There are other URL in title extensions for most browsers. And they're simple enough you can audit them or write your own.
This is how you mark up the expiry year in a credit card form:
<input autocomplete="cc-exp-year">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.
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.
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.
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
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.
Put in dollars, it probably costs 5-10 million a year (if not more) to test extensions even haphazardly.
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.
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.
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?
<input name="amount" type="hidden" value="15000">(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.
Making rent was kind of challenging that month.
It has happened quite often that I typed my PIN by habit and the machine just refused a tip amount that large, thankfully.
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)
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?
<span class="variable-amount">
$
<input class="variable-amount-input" type="text" style="width: 25px;">
<input name="amount" type="hidden" value="19900">
/year
</span>This story could have easily been written about a user who fat fingered an extra 0 in the field.
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.
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.
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).
Paste draws from the clipboard.
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)
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.
So ... you're saying it's the their own fault and Substack should keep the money?
Whether Substack should keep the money is a matter of goodwill, it's no different from the user fat-fingering an extra zero.
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.
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.
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.
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.)
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.
Ok, yes. Encryption could work, but encrypted passwords aren’t much better than plain text ones.
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.
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.
But yeah, that's infuriating.
It plugs in as an HID so that passwords appear to have been typed in, not PW managed.
Useful little thing, it seems too good to be true.
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.
That would probably be the best of both, no clipboard, and no browser addons.
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.
Makes them easy to use, with no saved PW.
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.
There is a standard for it, called TLS-SRP, but unfortunately no browser supports it.
[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/N...
That said, the implementation probably differs on different platforms. 1Password, for example, uses a virtual "keyboard" on Android.
It actually falls back to the clipboard [0], in a huge number of situations [1]. Basically, if Windows Forms isn't available/reliable.
[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...
[1] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...
Why only then?
If I have to do it, I immediately copy something else right afterwards, to avoid an accidental paste later on.
Could be better if it auto-cleared after a paste, but not sure how feasible that would be.