Let them paste passwords
ncsc.gov.uk
ncsc.gov.uk
https://github.com/jswanner/DontFuckWithPaste
I hate sites that do that (or prevent right-click as if that somehow secures their code).
- copy/paste hijacking
- sensor access: microphone, camera, GPS, etc.
Maybe even go further and introduce some sort of rate-limiting for
- XHR requests
- relayout events
to save power and data.
I _think_ that means it can send all of by passwords offsite, or do plugins need a separate permission to phone home?
https://security.stackexchange.com/questions/15259/worst-cas...
The plugin's code is probably quite short - maybe you could inspect it yourself, manually?
It's a bit disappointing that Chrome doesn't let you sandbox things well enough to install plugins safely; there's no reason that plugins should be allowed to transmit data without asking for permission.
[1]: https://developer.chrome.com/extensions/getstarted [2]: https://github.com/jswanner/DontFuckWithPaste
This ties in to the discussion of Craig's List the other day. It is so refreshing to use a site that doesn't try to be clever. I understand if people find it ugly, but I don't - simple is good, and I don't care if sites follow whatever design trend is hot this week. Usability is far more important.
I think that option is going to greatly constrain where you are able to go on the web. The vast majority of ecommerce sites I visit will break with JS completely turned off.
My experience is, that while ecommerce sites may break, most of them are quite usable even without JS.
Most good blogs work just fine. And the ones that don't I usually don't bother reading.
At one point, I built a sortable filterable table for an admin UI, using React. One of the admins was a "no js" guy, and he thanked me for building the whole thing in functional HTML. Up until that point, I had no idea that the admin side of the system was even usable without JS; that was just a natural consequence of optimizing for SEO and load speed (server side rendering, URL representation for all significant state).
I don't use Google services in my personal life. (I have less control over vendors at work.)
I roughly use OpenStreetMap 80% of the time, Bing 5% and Google Maps 15%.
Looking up where an address is? OSM. Routing? OSM. Opening hours for places I go semi-regularly (but not often enough to remember them)? OSM (I put them in myself). Footpaths, caves, info on towers (like GSM/3G), public transport routes, etc.? OSM.
Aerial imagery? Bing (much faster than Google Maps).
Traffic info? Google Maps (I'm still casually looking for alternatives). Searching a shop? Google Maps.
In the Netherlands OSM is of equivalent quality in some categories (road network, addresses), better quality in others (trails, meta info about towers or cave entrances or so), or worse in yet other categories (information about businesses, at least outside of city centers).
I also use extensions to enable them on certain sites. Just tap the extension icon and it will reload with JS enabled.
You'd be surprised how fast webpages load without JS
So basically you don't use 80% of the internet because the occasional site annoys you?
Do you also cut off your hands when you get dirt on them???
People have been saying this since like 2000's, and the more advanced JS websites get, the more cringeworthy this comment gets. It's 2017, just fucking leave javascript on and use ghostry + ublock origin.
1.) typing it out manually while you can't see if you made a mistake
2.) using developer tools to set the 'value' attribute directly
"SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right more reliably than my eyes and fingers.
Whenever I see a website that blocks paste I immediately assume it's built by incompetent people and trust it with as little as possible.
This makes me wonder about the personal security practices of the team that built it -- it's unlikely they typed strong passphrases hundreds of times a day during development -- and whether a secure site could come from such a team.
There are regulatory bodies that require regular challenge of user identity for approving items as sort of a signature mechanism. This is another time where active thwarting the password manager makes sense. Whether or not the regulation makes sense is an entirely different issue.
In the token case, I wonder whether they should have been password fields to begin with. Replacing a 6-digit OTP with asterisks is of questionable benefit, because the shoulder-surfer it thwarts can't reuse the OTP and is really unlikely to swipe it and use it before you do.
Only works with Internet Explorer
Doesn't work with Internet Explorer
Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc)
Passwords have no requirements
Right-click is disabled
Video plays as soon as the site loads
Share buttons that use javascript to follow the viewport
Share buttons that pop up over every single image
"Want to see more" when you move the mouse to the top of the screen (Or reach the bottom of the page) (or as soon as the page loads)
Slideshows of any sort
We don't optimize for impressions per session. Instead we optimize for the number of things a user does in a fixed amount of time, (or per session). The former is a poor proxy for the latter, and you can increase impressions by adding useless click through pages that ultimately drive away users and destroy your business in the long term. (In the short term, these things make your metrics look good.)
I bring this up because slideshows are a great way to artificially boost impressions.
should satisfy you both right? I use the original or a form of usually when I had to check emails.
dot-atom-text = 1*atext *("." 1*atext)
Why?
http://www.postfix.org/postconf.5.html#allow_untrusted_routi...
(Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)
And if you try to actually use a bare TLD you will crash hard into collisions with unqualifed domains and search paths. So, fun as a hack to amuse fellow techies but not useful for anything real.
In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.
Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept anything@user.dom.ain and turn that into user+anything@dom.ain, and it offers user@anything.dom.ain which it will deliver to user@dom.ain. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal foo+bar@dom.ain.
While I believe the + was common for postfix, exim and sendmail?
There even was a spam-fighting scheme that used this - it took a key, and optional date, and a sender address - and generated a unique address you could give out, that was only valid for a certain time, for a certain set of senders.
If the system received a mail with a from address that didn't match the cryptologically signed to-address (e12e-xjjgff65477fc@example.com) - the mail was held back, and the system generated a reply, with a signed reply-to address. A sort of manual grey-listing.
example+Youre+the+best!+Around!+Nothings+gonna+ever+keep+you+down@gmail.com
Too bad the music emoji is stripped by HN!
PS: Emoji in titles also make things like Youtube videos and blog posts pop quite a bit when shared via social media.
I believe I read that Facebook stores a few commonly mistyped versions of everyone's password. Actual password, typed as if caps lock was on, things like that.
I love how it's always the banks with these ridiculous password practices. I'm really glad that it's not some site where the password is protecting important information.
But if you use bcrypt you can partially compensate by using a higher work factor.
The 'correct casing' is any member of the set of all permutations of cases. So you both do, don't, and do not care.
Banks figured the cost of reimbursing people if their account is compromised is lower than the cost of having to field all of those phone calls.
Source: Used to work at a bank.
Once after my account was stolen from, I did a careful look at the website and sent in a list of questions and complaints about their practices. After enough bugging, a person eventually called me. The bottom line was essentially that I shouldn't be concerned because I'm not responsible for fraudulent withdrawals. It wasn't very satisfying.
The thieves got away with around $2400.
Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles.
I have no idea where this limitation comes from, do people just set an 8 character field in their database? Was this a problem decades ago that they figured they'd save a few megabytes of storage space?
I think they've finally changed it so that the reset period is determined on your password complexity, no length limitations, and you can have 2FA (or at least mobile password reset).
That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).
If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.
"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.
Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.
I'm having trouble imagining what scenario client-side hashing would protect against.
-- edit: using a KDF would improve it even more.
Developer: Similar passwords? Or Same passwords. Similar is hard.
M: Similar. Can't let people be lazy with their passwords.
D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...
M: Good! Let's do that.
D: ...but that could be a massive amount of space for long passwords.
M: Okay, we'll just enforce short passwords then.
D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?
M: Doesn't matter, the CEO said he wants this. Hop to it!
Developer laments the stupidity of their life
Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!
And further still, they don't need to _store_ all the hash variations
https://security.stackexchange.com/questions/53481/does-face...
Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.
man 3 crypt => https://linux.die.net/man/3/crypt
That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...
Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.
I made a saas tool for mac developers. Fixing all the quirks would cost far more than the potential 2% users are worth to me.
Slideshows - you mean even embeded Slideshare ones? Why? It's a good tool to explain certain ideas, and easily shareable one. We had our slides embeded on a TC post, and we used them as a significant source of traffic.
There was once a time where this was a workable excuse, but today's browsers are actually pretty good about following standards. If you're doing something that works in some browser, but not all, then you're likely exploiting some weird quirk of that browser.
And of course, not testing if it works in x browser is different than actively stopping your webapp from running if it doesn't detect the right browser/os combination.
I don't know what your product is, but I use four different browsers on a daily basis across three operating systems (it would have been six across 2 if not for the win10 privacy debacle, and even more if I had an android), and I want all my SAAS to work on all of them.
Experience says when they don't work everywhere, IT just dumps the service for another SAAS provider and everyone cheers.
Some of us just can't be bothered. My web app is tested on Chrome, Firefox, and Edge. If you want to use IE you are on your own and I won't support you unless you give me a million dollars.
I forget the term I did this with openssl, Apache, I think with a cheap vps I get between 9 and 10 cost, bcrypt. Sorry if these are not directly related for hashing.
A few sites I have to use for my dishwashing job work ie. share point and a card company that manages my money, as well as another by WalMart, they don't allow special characters only upper case-lower case and digits. You'd think okay length then but some have limits like a 15char limit.
That seems like it's asked with the expectation that the obvious answer is "no", but I believe it's "yes". Well, I have no idea of the quality of their devs, but someone in the decision chain thought that auto-playing videos was a good idea, and he, she, or they were wrong.
Or people will use 2-4 character passwords (often the initials of their name etc)
However; I worry that this is a very BIG assumption.
Even in my IT-literate circles password management usage is low.
In my non-IT circles it is non-existent, and not because of SPP particularly; I suspect SPP (which I agree is silly) derived from an understanding that allowing an average person to paste passwords meant they stored them in passwords.txt on their desktop.
Naturally the population here is technical so it can be hard to see that as a common and sensible thought process. But never underestimate the capacity of the average person (who's IT capability you and I don't represent) to make mistakes like this and never see the problem/risk.
It's odd that the article explicitly mentions this near the start but then doesn't address it in the Justifications section.
That's a significantly better practice than using the same easy-to-type password on every site, isn't it?
You are forked if your manager is ever compromised. It's only a matter of time until a major breach happens with a popular password manager.
You are forked if your machine is ever rooted too. Security isn't about perfection, it's about economics and threat models. For the average person the biggest fundamental risk comes from one of the vast numbers of services they use, none of which they have the slightest control over or knowledge of, getting breached, bought, leaked or whatever. As long as we need to use passwords (long past any technical reason for it, but legacy and inertia tends to make change extremely had) for authentication, it will in turn remain necessary for people to use passwords for every site that are good (random of sufficient length), unique, and can be changed at any given arbitrary time (in case of service compromise). It is simply not possible for most humans to handle all that in their heads, perfectly and indefinitely. Which in turn leads directly to password managers, end of story. It's not a matter of them being ideal or even desirable, they're necessary under current common authentication practices.
>It's only a matter of time until a major breach happens with a popular password manager.
Explain what you mean by this? Most password managers operate purely client side, and all actual password managers perform encryption client-side, there is nothing to "breach" to get general access to a wide swath. A persistent targeted threat is an entirely different scenario. Or did you mean you expect the password manager application software deployment system itself to get breached and thus release a malware infected update? That though isn't an issue limited to password managers at all, it's one that you can at least somewhat counteract yourself since it's ultimately on a system under your control (and there are OSS password managers, etc), and password manager devs have better domain knowledge and specialization then some random service.
In terms of threat model it's a no brainer. It's disappointing to see continued protestations against password manager usage on HN of all places, short of some theoretical discussion of switching everything to proper public key auth. Even a full court industry push starting tomorrow though wouldn't eliminate passwords for likely years if not decades, and in the mean time everyone has to make the best of it.
But that is password management, it's just crap password management.
There's certainly an argument that a plaintext-on-desktop stored list of high-entropy passwords is better than a single in-(human)-memory low-entropy password. With the recent wannacrypt reminder, that argument's slightly diminished, though.
I think the highest impact (i.e. fn of quick/low effort, high reward) suggestion to non tech-literate folk is to use 2FA on their email account. I like and usually suggest Authy, mainly because it's available as a Chrome app too whereas e.g. Google Authenticator is just on Android/iOS. (I assume it's clear, but email account as opposed to something else since it's so near universally treated as the fallback option.)
That's a good base for them to start using 2FA everywhere else it's possible, too.
For sites that disable pasting, I have developed quite a skill at copying the password character by character from my PM into the password field. I'm even starting to remember a couple of them.
Incredibly frustrating.
My password manager also clears the clipboard if it is equal to the last password copied after a wile (I've never timed it).
I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?
Although, honestly, the other part seems more bizarre. Gov't agencies and other clients are just giving you their sensitive passwords, and trusting you to delete them after the project, at your leisure? How is that not terrible security? Revoking a consultant's security needs to be in the hands of the employers.
But why even know your own passwords, what is the point? If I can double click from my manager and paste it into my password field and never have to worry about knowing anything, I'm much happier and safer.
For Firefox, setting the "dom.event.clipboardevents.enabled" about:config option to false prevents clipboard paste events from reaching javascript. No more blocked pasting after you toggle that option, even if the website attempts to do so.
The AppleScript in question is very simple, it just looks like
on alfred_script(q)
tell application "System Events" to keystroke q
end alfred_scriptThis is my pet peeve. Password fields should not be obfuscated by default. It should be a toggle that is off on page load. Shoulder surfing is a corner case.
eg. echo "type password" | xdotool -
Oh, and if you forget your login/pass/security-answers, don't worry, you can just re-register your account with the same username as before, with all new password, security questions and answers.
As in... every login it wants you to answer all six of your questions? That's barmy.
if you can remember your password, its probably too weak
Now I use a hardware token (yubikey) to store my PGP key so I can use a relatively weak PIN code on it (since you need to have physical access to the device to use it and you only have 3 attempts before it locks up). It's a pretty good quality of life improvement.
Then you better don't use it when you're fatigued or drunk. I nearly locked my SIM card once by not realizing until the third attempt that my phone was asking for the SIM card PIN rather than my lockscreen PIN.
Well, unless I'm silly enough to try and bruteforce that PIN as well, after 3 failures I'd be left with an expensive piece of plastic... Fortunately I'm rarely that drunk.
EDIT: Actually as the sibling comment points out you can still reset the token even if you mess up the admin PIN. So at least you won't "brick" your token completely.
hunter2 is the password manager I wrote for this: https://chiselapp.com/user/rkeene/repository/hunter2/
- If it's a website I couldn't care about, I use a simple password, probably a remnant from growing up.
- If it's a website I'm concerned about but knowingly won't use, I create a random password and clipboard it during initial creation/login, then every time I use the website I reset it (lazy man's password generator)
- If it's a website that I care about, like HN, I have a loose pattern that I follow that includes symbols and numbers (that's the 30ish character I was referencing). Every website is unique.
- Financial accounts have their own set of rules (unless it's stupid and has, say, an 8 character limit)
- My main email accounts get special treatment with an exceptionally long password.
- Use two-factor authentication wherever possible.
And yes, I could replace this with:
- Password manager
- Two-factor authentication
E: grammar.
For instance, if I needed a new strong password, I could use, "This#jar#once#held#1111#M&Ms,#but#now#it#is#empty."
The only thing I need to remember there is the story of the jar and the padding character I used in place of spaces. If I really had to, I could put "#" on a sticky note under the jar. But of course, I can't use that password now. So I might instead use "I(used(this(jar(as(an(example(on(HN." But now I can't use that one, either. So maybe I use "These!blinds!are!very!dusty.!!Someone!should!clean!them." or "My^dog^once^killed^a^dozen^baby^rabbits^in^the^tall^grass^I^didn't^want^to^mow." or "MyFgreatFauntsFhadFreallyFlongFhair."
I get really irritated when sites tell me I have to include numbers, uppercase, lowercase, and symbols in the same password. I get especially irritated when they put an upper limit on the number of characters, or ban certain characters from appearing in the password.
But everyone has their own tricks for remembering things.
And I certainly don't make the effort for sites that I don't consider to be important. Those as often as not just get reset via e-mail whenever I forget my password.
Use a password manager. KeepassX is free, cross-platform, works on phones, does all that work for you, secures even your least-valuable accounts, does things right, doesn't store your passwords "in the cloud" and you'll get to keep applying your scheme to your master password.
Why would anyone do that, when those digits can so easily be calculated or referenced from data files? Why do anything that is not strictly necessary? Why try to bench press more weight than last time? Why try to improve your chess game? Why learn a new programming language?
Because different people like different things. I am not required to like the things you like.
And I like proving to myself that I still can remember things without a helper daemon to keep track of them for me. I like that little bit of paranoid fantasy I have that makes me think that the men in black suits would have to take the pipe wrench to my kneecaps to get at my passwords, so I don't think about how the security at all these sites requiring password is so piss-poor that it would be easier to bypass all passwords in lieu of cracking just one of mine. In the end, the problem mentioned by the article is that very few people implementing computer security measures have any idea how to truly secure their data, so they do stupid shit like block clipboard pasting into password entry fields, or allow accounts to be hijacked by a spoofed SMS 2nd factor, or try to roll their own crypto without the requisite number of CS and math PhDs.
Probably the best argument against spaces is the attack that listens to the sounds of your keyboard with a microphone as you type. As the space bar is a larger key, it sounds a distinctively lower note as you type, and would give even an unsophisticated attacker the means to determine the word lengths in your passphrase, which might reduce its entropy to something guessable within the lifespan of the universe.
Probably not a concern unless you might be targeted by someone with government-level resources.
If you're using about 8000 words, randomly chosen, then a 4 word passphrase is about the same as an 8 character random password. (And in fact, for 8k words, it's basically a direct substitution between 2 characters and 1 word.)
For most intents and purposes, 8-10 characters is fine, and 20 characters is enough to use as a cryptographic key. Similarly, 4-5 words is fine for most uses, and 10 words is enough to use as a cryptographic key.
So I'm not sure what you think isn't effective about passphrases -- they're just using a 2^13 sized alphabet instead of a 2^6.5 one, but either is capable of being used to write down a random string of bits.
The argument I am making is that your average passphrase — yes, including "correct horse battery staple" — could be cracked a trillion times over before a password generated via 1Password would be!
As XKCD famously pointed out[0], Diceware[1]-style pass phrases can be both secure and memorable. XKCD's four word example isn't secure when fast brute-force attacks are feasible, but eight words is still easily memorable and secure enough for anything. The important point here is that "random words" really does mean "random", i.e. not picked by a human.
> Distributed_By: WalgreenCo. 200 Wilmont Rd.
And it would both be very strong, and be difficult for someone at my desk to guess by looking at things on my desk.
Diceware, 6 words 2.2 x 10^23
Diceware, 5 words 2.8 x 10^19
Diceware, 4 words 3.6 x 10^15
a-zA-Z0-9, symbols, 10 4.3 x 10^19
a-zA-Z0-9, 10char 8.4 x 10^17
a-zA-Z0-9, 8char 2.2 x 10^15
Diceware, 6 words 77 bits
Diceware, 5 words 64 bits
Diceware, 4 words 51 bits
a-zA-Z0-9, symbols, 10 65 bits
a-zA-Z0-9, 10char 59 bits
a-zA-Z0-9, 8char 50 bits
It's highly amusing when a site tells me that such a password is insufficiently complex, given that it will never in the lifetime of the universe be guessed.
The entropy calculations are probably generous. The wordlist isn't as long as it looks, because some of the words are strange and people tend to re-roll if they get something like that. It's probably better to assume there's only 1000-2000 "words" people will safely combine.
Also, the combinations list assumes that the attacker knows the method/word-list used to generate the password, which may not be foreknowledge the attacker has access to, especially in cases of giant many account password brute forcing attacks.
Just because your passphrase may essentially be a PIN look up into a lookup table doesn't mean the attacker knows that or has access to the same lookup table.
You can also add additional entropy via punctuation or casing.
The point to a random passphrase is to try to avoid "human" mistakes like over favoring a subset of words, and rerolling words you don't like potentially makes your collection of passphrases more susceptible to analysis or social engineering (word association) attacks.
Like I said, it's generally better to pick a word-list you are comfortable with all the possible words than to subset a word-list you aren't entirely comfortable with.
The goal of something like Diceware is to be easy for humans to memorize but also still true random (see: xkcd's battery horse comic). If you don't need to memorize it, then yes, why not entirely generate a random sequence of letters/numbers/symbols/emoji.
If they disabled pasting, I'd disable my account.
This really pisses me off every time I see it.
JavaScript is client-side code. If the attacker you're protecting against can't trivially bypass this bullshit "security" feature in three seconds, then he/she is not something you should be concerned about.
Attackers like that probably have other skills like counting to 5 with a 60% accuracy, and pointing out their own nose with a 40% accuracy. (Just like you do if you have this on your website.)
Even worse: sites that silently truncate your pasted password to the maximum length. When all you see is those little dots and the password is wider than the text field, it's very difficult or perhaps even impossible to tell how many characters were successfully pasted. And obviously truncation sets you up for disaster when you try to log in using your saved password and it just doesn't work.
That assumes they're not storing your password in a VARCHAR(16) field, which is what I always assume when I see a max password length restriction like this. Or perhaps they're using the ridiculous LANMan hash algorithm [1].
[1]: https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details
> Most password managers erase the clipboard as soon as they have pasted your password into the website, and some avoid the clipboard completely by typing in the password with a 'virtual keyboard' instead.
Isn't the latter approach much safer? If so, shouldn't it be the de facto standard since it prevents "clipboard stealing" and also removes the issue of not being able to paste content into an SPP form input?
For example, my bank's app don't let you paste passwords. I have a strong random password which basically means I can't access it from my phone...
I had to just throw up my hands and do all of my access to chase.com through a sandboxed browser profile, where I could automate logins.
I'm not fond of this, but what does it have to do with passwords? I (reluctantly) use Chase's online banking on the desktop, and it lets me paste passwords.
The best solution I found was to mount via the command line but that definitely wasn't an option for any coworker unfamiliar with the terminal.
https://apple.stackexchange.com/questions/42257/how-can-i-mo...
Also while this may be ultra paranoid, I really don't like typing passwords in public places where endless he cameras can record my screen and keystrokes.
It's like it's on purpose to make you save the password on the keychain or to make it more predictable somehow. I think that's either a very bad decision or evidence of NSA/CIA infiltration/influencing of Apple's software
Since I can't have the password visible in the password manager on the phone at the same time as the login prompt in the app, this means that I can only use the bank app if I'm 1) next to another device I can get that password on or 2) if I write the password down on something.
- Allow you to paste passwords into their smartphone app, but not into their web site being accessed from the same device.
- When entering new passwords, limit the password length but not tell you what the limit is ("password is too long"), so you have to reduce it 1 character at a time and keep trying.
- (Mentioned elsewhere in this post) Limit the special characters to some inexplicable subset like !@#$, so you have to edit your generated random password and replace the non-compliant characters with ones from their subset.
- Limit password lengths to (say) 20 characters, allow you to enter a new 20 character password, but only store the first 19 characters so you get an invalid password error when you subsequently log in! I figured it out because I knew I was pasting the correct password, so I just thought, "Hmm, UI team != DB team..." and tried one less character. Bingo.
This happened to me with an old version of (IIRC) a Bank of America iOS online banking app (I am not concerned about mentioning a name here because it's been fixed since then).
- Limit your password to something really short like 10 alphanumerics.
- Require password entry for (say) iCloud before you can get into your password manager, forcing you either to pull up the password on another device and painstakingly enter by hand a 30 character random string, including many special characters, and not letting you see the password (only the last character, for a second). This is so unpleasant that I am sure many people would just change the password to their dog's name or something.
On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario.
1) User tries to type "mypassword" but enters "mypasswor" instead.
2) User copy-pastes "mypasswor" into "confirm password field"
3) User hits "submit".
Now when the user tries to login with "mypassword" it fails.
It's a shame that password managers are mostly used by tech savvy people, as they are probably the most secure way to deal with passwords we've come up with so far.
When changing your password, if you're pasting at all, it's from another (presumably correct) source -- so pasting is fine, whether once or twice.
I would paste into both boxes and resort to developer tools if I am not allowed.
Maybe they're worried people will have a "password.txt" in My Documents where they store all their passwords in cleartext. That being said it'd still probably would be more secure than having the same password everywhere like most people seem to do.
The road to (UI design) hell is paved with good intentions.
Whilst we're on the topic: I hate stupid input fields that don't ignore whitespace and have a maximum number of characters. So you paste the space-separated number (I'm looking at you IBAN), get an exception because of the spaces, go back and remove them, get another exception, and then realise that the number was truncated due to the field length restriction applied on paste. ARGHHHHHH
I disagree with this. If you paste a password into both fields, then paste it into your password manager, it doesn't matter if you've copied the wrong thing, because your password manager will still remember it.
I feel passwords used to be thought of as a combination of characters that you keep in your head, and should only leave your head when being entered in a password field. Preventing paste discourages storing your password in a file called passwords.txt, and accidentally pasting it somewhere else as well.
Of course, we now understand passwords should have some qualities (larger alphabet, avoid common words/phrases as your passwords) which go against ease of remembering, so we now use passwords managers and other tools.
So this behaviour is probably and old common practice that most people used without knowing why and that's why we still see it even if its outdated and harms security in the end
Nobody other than those who use very simple, high risk passwords can remember them all. It has to be stored somewhere. Preventing copy/paste seems like a completely useless step (security wise) that only causes unnecessary bother.
Similarly with Post-It Notes and physical written Notebooks of passwords. If your threat model isn't concerned about people with physical access to those notes, and you are comfortable with the physical security of those notes, that can be perfectly acceptable for you, and an overall better security stance from bad passwords.
"Don't write down your passwords", has always been bad advice, from that perspective. "If you write down your passwords, keep them safe" is slightly more accurate.
Humans (in general there are some exceptions) aren't very good at remembering large numbers of arbitrary long random strings.
So using a password safe and then copy/pasting into the relevant dialog is likely to be a better option than relying on human memory (which inevitably means for most people using the same password in many places)
Passwords operate under the principle "something you know". (Unfortunately operating under this principle on the Internet is quite hard, but that's a different story). When you save passwords somewhere it's no longer with the assumption of being just "something you know", but more "something you have". Of course passwords are even less apt as "something you have", because they are hard to secure, both in storage and in use.
Nothing has fundamentally changed. That people can't imagine why someone would want to keep passwords "something you know" is because they don't understand they theory behind passwords. A password manager might seem like a solution, but in reality what you're getting is the worst of both worlds. You don't get the security of "something you have", like a key that can be stored in hardware and verified with disclosing it to the host. Nor do you get the flexibility, at least not as a user, of "something you know".
I actually think it would be a great idea to block password managers and offer an alternative protocol for authentication. That way if they want to keep their users they would have to implement that protocol. Suddenly you would have quite a lot of users using something more secure.
(just a random text on the subject: https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeopl...)
All of that meant that someone launching a service couldn't assume that their users’ software supported encryption at all or securely for years. Coupled with the previously mentioned horrible user experience and cost of certificates, that really killed the idea since the password experience was both easier and far more familiar.
1. https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
1) In the beginning the whole X.509/PKCS PKI mechanism was seen as something that came out of X.500 and other telco stuff, is centralized, complex and expensive (all of these things are in fact true for the originally envisioned usage) and thus irrelevant for decentralized internet. (for example, the L for "Lightweight" in "LDAP" essentially means that it uses passwords instead of client side certificates)
2) The UX in early SSL capable browsers for client-side certificates was horrible (In Netscape the whole SSL configuration was in completely separate dialog from browser settings, which was incredibly complex. IE uses SSL implementation from windows which is also used for lots of other things and has centralized configuration and also even today creates confusing dialogs when site requests client certificate). It's somewhat ironic that various ActiveX/Java based replacements of this horrible UX are in fact often even more unusable.
It was even backwards-compatible with X.509!
If you don't use a hardware module certificates are easily stolen by malware and as revokation is often problematic, stolen certs can be quite bad news.
For what its worth I did write a small utility to make it easy to create memorable passwords using a master password:
https://github.com/agentgt/ezpwdgen
It uses the Emoji word database to help you remember passwords.
I've never actually managed to find out where the idea of websites banning copy/paste came from. Presumably it's been as a result of security audits, but I can't find any security people who would argue that it's a good idea...
If you can run Wayland, do it. If for no other reason, this.
You need to have cursor focus to receive key events, right?
The clipboard, by contrast, can be continually monitored, while playing completely "by the rules", right?
It does allow you to paste into the login fields, but you cannot submit your login credentials this way because the "Sign On" button is greyed out until you've actually typed in each field. I let my password manager fill the fields, then I manually delete and re-type the last character from each of the 3 fields.
Also, many sites should have an easy email based login.
> Justification 2: 'Pasting passwords makes them easier to forget, because you have fewer chances to practise them'.
Difficult to remember and easy to forget passwords will be auto generated. In fact I encountered few websites that didn't accept long passwords.
> Justification 3: 'Passwords would hang around in the clipboard'
Only for 12 seconds after which keepass will clear the clipboard.
The more common place I've seen it is email address confirmation (or PW confirmation), which while probably unnecessary, is not the worst thing in the world. You are retyping an address that's displayed in the field above. Less intrusive than a captcha.
Password managers could wipe the clipboard, if it still contains the password, after a defined amount of time, such as 60 seconds.
(If you think that's "confusing", show a notification that explains the behavior; "clipboard wiped" or something.)
Password managers are a thing. Please don't force me to type out 32 random symbols twice while I sign up for your service.
The QQ messenger blocks pasting passwords on iOS I suspect for this reason, perhaps there are teams of people guessing passwords and manually typing them in like gold farming.
From what I gather this should use IPC between applications, rather than the clipboard itself.
Another annoyance is having to enter 2nd,4th,7th etc letter of the password using a dropdown. ARrrgh.
If the problem is the risk posed by password vaults and clipboard managers, promote better vaults and better utilities. Personally, I'd love a password vault that could check which application or website I'm pasting to, blocking transmission if it looks wrong. But it's not the website's job to tell me how to manage my secrets.
Whereas if you reuse a password on multiple sites, and one of those sites is compromised, all of the rest of your logins are compromised.
My largest issue is that its extremely possible to fat-finger your UN to be Hellow, and its extremely easy to see and fix that mistake.
However since passwords are hidden its hard to see ######## is actually Worls123. Now your new account has essentially a one-time login because you have no idea what your password is. Typing it out again, ensures you catch your mistake
I'd notice someone shoulder surfing so I'd prefer if they wheren't starred out by default with starring out as an option if I do have people around.
I never need passwords hidden in my home. I've been in work environments where I know I'm not doing anything where I'd want passwords hidden. I especially don't want passwords hidden on my phone, where it's easy to make a typo.
What I am saying is that from a regular user's perspective there is no viable way to do it right and we shouldn't be surprised if people follow bad practices. We can't just tell people to:
- don't write down passowrds - have unique strong passwords for dozens of sites - always type them in
It's not going to happen.
That seems to be the key issue.
I once spend several weeks having meetings where people tried to develop a login management process on a whiteboard from first-principles — in the federal government where the right answer was “We'll follow the central security group's required process” – because they didn't have a security consultant but knew security was a Really Big Deal and didn't want anyone to think they weren't thinking about it.
You might want to allow paste, too, but it's the clumsy solution.
But we don't disagree, folks should definitely implement things like OpenID.
This is a huge step up from a memorized password. Go ahead and implement OpenID too, but don't force people down to the level of memorized passwords needlessly. Expending effort to prevent pasting is a stupid move.
Oh, I agree. I was more talking about people who have already expended that effort (so its zero marginal effort) and are considering reversing it (which as a small but non-zero cost.)