I can give 2 real world examples of stupid security, or where rules are made without employees truly understanding why.
First, in the UK about a decade or more ago you used to have to sign the receipt and the checkout staff would check it matched the one on your credit card. There came a time when my credit card expired, so I produced a new one from my wallet. "It's not signed" she told me. So I signed it in front of her, then she gave me the receipt to sign, which I did. She then checked to make sure both signatures matched! Even though she'd seen me sign them BOTH in front of her.
Secondly, my wife tried to take 6 items into the changing rooms but was told they have a maximum of 5. I have no idea why. I mean, theft is theft regardless of how many items, right? Anyway, she handed one item over and took 5 in, and they gave her a plastic sign saying 5 on it. The idea is if you take 5 items in then they check that you bring 5 items out with you. Anyway, when she was in there she asked me to swap items around - go and get her 2 belts, swap the jeans for a different size but bring 2, etc
So, at the end she came out of the changing rooms with 7 or 8 items. The assistant took the clothes she didn't want and put the sign back ready for the next customer. At no point was she challenged about why the number of items she had didn't match the sign, all their "security checks" were done to make sure she couldn't try on more than 5 items at a time.
I wrote to the store but naturally received no reply.
I think the story with the credit card makes more sense than it seems at a glance:
They want to make sure you hadn't intentionally produced two different signatures. I think, in theory, you could later dispute the charge and the merchant would have nothing on you, if the signature didn't match the one on the card.
In Germany, when the DHL delivery guy is unable to give you the package in person, they'll put a yellow note into your postbox and bring it to a nearby package store. The next day you can get the package in exchange for the yellow note, provided the recipient address matches your ID card.
If you had it deliver to a different address than which you are registered on, the store clerk is (technically) not authorized to hand it to you, because the addresses don't match. But the backside of the yellow note has a mandate form, which you can use to authorize any person to fetch it for you. So if the clerk refuses to give you the package, you turn the yellow note around, fill in the form and authorize yourself in front of their eyes to get it anyways.
I never understood signatures, but then my handwriting is all over the place and at best my signature is a squiggle.
I haven't a clue how they're verified these days. I suspect they're basically a legal guarantee, where in court you can be asked "is this your signature".
> so I produced a new one from my wallet. "It's not signed" she told me. So I signed it in front of her
I’ve had this too. It felt weird, but isn’t that bad: You sign just the same before a second attempt, so might as well continue. And the upside of having to do this ad hoc is that it’ll help on future card usage.
But the following likeliness check is hilarious of course. :)
My passport is from a “top” country. To get it I only needed a photo and my birth certificate, which I bought a copy of from a government office for a small fee. Then a signature from police department to say it is “my” certificate to accompany my photo.
When I was renewing it in a foreign country I filled out an application online and had it sent to my new foreign address without any checks. Perhaps the embassy checked on my residency but any ID in my new country has been issued based on that passport.
At my work we signed a deal with one of the big three credit reporting agencies that had a well publicized security breach a little while back.
As part of this, they sent us some security due diligence questions, which is fairly routine. One of the things that they wanted us to agree was that we forced all of our employees to change their passwords every $timeperiod.
They insisted that this was important for security, and only backed off after we sent them references from all of microsoft[0], nist[1] and the uk national cyber security centre[2] saying that doing so would reduce security.
My suspicion though is that they only removed it from our specific contract, and they hadn't changed the entire process. I would have hoped that after their security breach (this happened afterwards) they would have reviewed their security and improved it but unfortunately that didn't seem to be the case. There were a fair few other things in the review that were generally poor security wise, but that one is the one that stood out to me.
I protested this exact thing at $workplace last year, but they said that the NIST recommendation was "only a draft", and that the NZ government security services hasn't yet updated their recommendation. So here we are, incrementing a number every couple of months to keep the robots happy.
One of our vendors started requiring a monthly password change. Now, you can walk through the office and see half a dozen passwords on Post-It notes in plain view. I explained this to them, and received a response that seemed to think I was asking what a password was for.
I once went through a couple of cycles of: Create account, do things, log out, try to log back in: Invalid password. After 5 times of resetting the password I had an idea, may it be that they truncate my 32 char random string from Bitwarden? So I paste the first 12 chars (after a lot of tries I was down to 12), voila.
I can't remember the company but it was not a small one... The stupid thing was that it accepted the original input but simply truncated it, no warnings.
Sounds like some banks I’ve dealt with. They all seem to have ridiculously short password limits. I’m guessing they store them in plain text in an ancient mainframe.
This happened to me with paypal which had a max password length for some reason at one time. When entering the two masked passwords it just discarded anything I typed beyond 20 characters instead of throwing an error "password to long" when I hit submit.
I've run into the same thing a bunch! I wish I could remember the companies to "name and shame". Some of the variations on password complexity I've seen have been:
1. Allows any input length for password, but has a limit of X characters. Annoying because it makes it a guessing game, like you were talking about.
2. Stops accepting input for password after it hits X character limit. Annoying because you can go for months thinking you're using a 30 character password, and come to find out it's actually 8. Hard to catch if you aren't paying attention to how long your obscured password is.
3. 1 or 2, but they have a rule against all special characters. I think this is supposed to be some weird attempt at preventing SQL injection?
4. 1 or 2, but they have a rule against all special characters and numbers. I've only seen this once, but I remember dropping the service after I realized what the problem was. It was years ago, during the era when something like "banana" or "pencil" was considered a strong password.
5. 1 or 2, but they have a rule against some special characters. Usually ! @ and #, or ! # % will be permitted, but other special characters will not be permitted. I suspect this is because customers "keyboard walk" with shift+123. I.e. asdf123ASDF!@# or QWER!#%qwer135 Basically, the company allows for more predictable passwords in order to prevent extra tickets being filed.
Generally, when I run into login problems, I drop my password down to 12, since that's a pretty common length; I believe it meets a minimum length for a DOD standard? If that doesn't work, I drop it down to 8. If it's still not working, then I start removing special characters and capitalization.
It's really gross that I can't expect to use a 30 - 60 character password in a predictable manner across the entire internet. In a way, I almost prefer things to be the way they are though, so I can have a better idea of which companies are strong on security, and which are either uninformed, or justify misconfigurations as "improving customer satisfaction" over minimum security policies.
> Because security questions are nuts! I mean those ones are extra nuts but in general the whole idea of taking either immutable pieces of data like your mother's maiden name or enumerable questions like the make of your first car or transient ones like your favourite movie...
I always use a randomly generated string with a high entropy as answer to the security question.
I once used a randomly generated word as the answer. But the darn thing required five security questions and answers, so of course I just reused the same answer (random, unrelated to the question) across all five.
On fine day, I had to call in to the support for something or another. He's like "I need to ask for the answer to the security questions", I'm thinking "no problemo" and I kid you not, the agent asked all five questions. By the last I'm thinking "surely you can't think I'm going to miss this one?"
Edit: it also reminds me of Rackspace! If you initiated a customer support request — for which the button was in the console, after logging in, the agent would ask the security question. The answer to which … was in the same console!
1. e-mailing passwords and personal information (because customers need doxed by their e-mail providers)
2. shipping commercial beta source code to customers because someone was too impatient to learn how to package the product with a clearly labeled build script
3. shipping master x509 signing keys to random users because they are "good people" and can be trusted
4. deleting random database records with administrative privileges because it looked complicated and messy. Then tell users to pack data into document labels after destroying the key relationships.
5. goofing with passwords, then issuing a support ticket when they get auto-banned from the system
If you think an external adversary is more dangerous than someone who shouldn't have administrative privileges, than you have never dealt with real sentient liabilities.
VMS OS from DEC had exactly the "unique password" stupidity in the late 80s.
In a way, it was much worse than Twitter's, because where I worked there were only about a 100 accounts, so you could find the other by hand in less than an hour.
Is it really worse than Twitter's? The image has the website telling you exactly which account is already using that password (it's actually a joke from reddit).
It's interesting to know that this was actually a thing though...
This is from Troy Hunt of Have I Been Pwned fame and I'm almost positive that even in the last year he still gets legal threats from companies that he contacts about embarrassing security risks.
They now need to be made enforceable, whether by government requiring them in government contracts, or indirectly by insurers excluding coverage if they are not met.
No, because what will happen is that the standards won't be updated for 10 years, and they'll be outdated, just like all "enforceable" standards created by the US government.
I was hoping you'd have given up on UW after that. They're a bunch of scamming bastards who will pester you endlessly to go out and sign up more people to UW.
When you see sense and stop using UW, they'll send you bills for random amounts of money for *years* afterwards.
I am dealing with a problem with UPS MyChoice at the moment. I signed up with them about 3 years ago, and used a long randomly generated password (as you should), which had several punctuation characters in it. Today I am unable to log into the account because of this - they apparently changed the password complexity rules at some point to only allow a single punctuation character. And they seem to be applying the new rules at login.
Bonus: the password reset process is broken - their customer support doesn't understand that I don't have anywhere to enter the PIN they emailed me since the website errors out. "Just enter your PIN" "Where? I only see the LASSO_1010 error message telling me to call you."
After hanging up on them after 40 minutes of frustration I decided to go create a new account. But can't because there is already an account for that address.
There are different kinds of regulation. They don't necessarily need
to be prescriptive or to test static quality in the same way that
drugs are regulated. (But I think that some security people would like
them even less than flat-out being told what code to put in their
sites.)
Instead of regulating the product, you regulate the processes around
it. Why?
The assumption is that users are stupid, but security people are
clever. A side-effect (lemma of this axiom) is that security is for
control rather than safety. Ergo - safety emerges from control.
Security becomes power.
But as we see, frequently mother does not know best. The fact is that
some security people are stupid (it's difficult and not the highest
paying job out there) and a few users are actually very clever. Now,
if the clever ones are malicious (bad hackers) you've got
problems. But in reality far more clever users are benevolent and
would choose to participate in a "security culture" if it were
encouraged rather than imposed on them like children. It's their data.
As it stands our security culture leads not just to dismissive
authoritarianism but unassailable systems that may not be questioned.
Regulation that puts much more power into the hands of all
stakeholders can be a great alternative to ever more compliance and
auditing imposed top-down (which is really a weak solution to a
dynamic problem: security changes almost daily).
Consider a regulatory mechanism like the GDPR that allows users not
just to know what data is held, but how it is protected and to
request (with some force) changes to that protection.
Taken to the limit, let's call it "User Side Security" (USS), we build
interfaces so that the user gets to decide their chosen security
solutions (obviously compartmentalised so as not to affect any other
users assets or choices).
(I feel a tremor in the Force, as if a million security people
suddenly cried out in horror then suddenly fell silent.)
But this would provide the bottom-up incentive for firms to get their
PII-security systems back on track without Byzantine top-down regs
which I guess the industry fears more.
Is it weird to say that these issues are too stupid for software engineer licensing to be a good answer? It's like buying a fleet of cherrypickers to pick lettuce.
And if we can't hold people accountable for their actual products being laughably insecure, I don't see how licensing enforcement is going to go better. For starters, the question of who should be required to hire licensed engineers is the same as who should be regulated/sued into compliance/oblivion regardless of licensing, and we clearly can't do that.
I’m very new to this concept.
What would that actually look like? What kind of rules and regulations would be put into place and how would that affect e.g. building websites with logins?
> blocking pasting is bad because it blocks my password manager
again this is just a very ad-hoc opinion, theres nothing stopping a password manager from faking keyboard inputs, or the browser from having a mechanism for supplying a password externally. that said, blocking pasting is fucking insanely stupid and shouldnt even be something web apps have control over. incidentally, the same "we dont have to concretely define anything" mentality is the same behind both issues here: allowing browser control over paste is a way of letting the app implement 1% more applications that would be impossible otherwise, while breaking stuff by ruining the abstraction; and providing a password externally would require inter application API which always fucks up because nobody has the balls to define anything concretely.
Don't know if I should share it here but hey, we all make mistakes :)
I had to implement a "forgot password" feature in a web application. I implemented it via:
1) Take the user's email
2) Generate a 6 digit code
3) Send the code to the email
4) Send the hash of the code to the frontend and save it in local storage
5) Compare the code from user which they get via email to the hash in local storage
Someone could change the hash in the local storage and bypass this.
Of course, I reverted to use Redis instead of local storage for this after like 3 days, fortunately with no mishaps.
I've since then made up my mind to not implement bad workarounds like this because it just felt so wrong.
One of my favorite "Stupid Security Things" is when creating accounts on banking, government, and other critically important websites and I'm met with stupid password requirements which actually forcibly reduce password security like "Sorry, your password may only contain letters and numbers. Special characters are not allowed."
(Believe it or not, this has been a far more common occurrence than it should be… Sometimes it even goes a step further by additionally limiting the length of the password to some insanely short length. "Must be between 2 and 8 characters." for example.)
The checkout one is down right stupid. Like you have to put in effort to do something like that (design something like that) - like it is so easy to NOT do that.
Not sure how people end uo designing websites like that by damn. Also that Xbox HDMI cable was hilarious - I need one too because those viruses can easily enter my home network through a virus noise (like COVID) that attaches to the HDMI!
Isn't there a massive security concern in exposing the username of whom you share a password with?
I type `password123` or a range of other passwords, find a silly user using that, try every other major account providers with the username/password and I have access to that person's account?
It's also often not difficult to guess someone's email address from their username (to find more logins) since there are only a few major providers, which such silly user would definitely use.
At this point I'm tempted to think we ought to be managing our own domain instead of email so we can ditch a breached email whenever it is leaked. Together with the use of virtual credit card to limit the exposure. It doesn't stop website collecting other kind of sensitive information like addresses and phone number though
[+] [-] jjbinx007|3 years ago|reply
First, in the UK about a decade or more ago you used to have to sign the receipt and the checkout staff would check it matched the one on your credit card. There came a time when my credit card expired, so I produced a new one from my wallet. "It's not signed" she told me. So I signed it in front of her, then she gave me the receipt to sign, which I did. She then checked to make sure both signatures matched! Even though she'd seen me sign them BOTH in front of her.
Secondly, my wife tried to take 6 items into the changing rooms but was told they have a maximum of 5. I have no idea why. I mean, theft is theft regardless of how many items, right? Anyway, she handed one item over and took 5 in, and they gave her a plastic sign saying 5 on it. The idea is if you take 5 items in then they check that you bring 5 items out with you. Anyway, when she was in there she asked me to swap items around - go and get her 2 belts, swap the jeans for a different size but bring 2, etc
So, at the end she came out of the changing rooms with 7 or 8 items. The assistant took the clothes she didn't want and put the sign back ready for the next customer. At no point was she challenged about why the number of items she had didn't match the sign, all their "security checks" were done to make sure she couldn't try on more than 5 items at a time.
I wrote to the store but naturally received no reply.
[+] [-] forkerenok|3 years ago|reply
They want to make sure you hadn't intentionally produced two different signatures. I think, in theory, you could later dispute the charge and the merchant would have nothing on you, if the signature didn't match the one on the card.
Not to say that it's a flawless safeguard :)
[+] [-] blueflow|3 years ago|reply
If you had it deliver to a different address than which you are registered on, the store clerk is (technically) not authorized to hand it to you, because the addresses don't match. But the backside of the yellow note has a mandate form, which you can use to authorize any person to fetch it for you. So if the clerk refuses to give you the package, you turn the yellow note around, fill in the form and authorize yourself in front of their eyes to get it anyways.
[+] [-] Cthulhu_|3 years ago|reply
I haven't a clue how they're verified these days. I suspect they're basically a legal guarantee, where in court you can be asked "is this your signature".
Digital records are IMO better.
[+] [-] talkin|3 years ago|reply
I’ve had this too. It felt weird, but isn’t that bad: You sign just the same before a second attempt, so might as well continue. And the upside of having to do this ad hoc is that it’ll help on future card usage.
But the following likeliness check is hilarious of course. :)
[+] [-] jdthedisciple|3 years ago|reply
I probably has more to do with not wanting too many items to be simultaneously unavailable for other customers, which makes sense.
At least that's how I always viewed it, maybe someone can confirm or deny.
[+] [-] janeway|3 years ago|reply
When I was renewing it in a foreign country I filled out an application online and had it sent to my new foreign address without any checks. Perhaps the embassy checked on my residency but any ID in my new country has been issued based on that passport.
[+] [-] deserted|3 years ago|reply
[+] [-] mhb|3 years ago|reply
https://en.wikipedia.org/wiki/Sphex
[+] [-] mijoharas|3 years ago|reply
As part of this, they sent us some security due diligence questions, which is fairly routine. One of the things that they wanted us to agree was that we forced all of our employees to change their passwords every $timeperiod.
They insisted that this was important for security, and only backed off after we sent them references from all of microsoft[0], nist[1] and the uk national cyber security centre[2] saying that doing so would reduce security.
My suspicion though is that they only removed it from our specific contract, and they hadn't changed the entire process. I would have hoped that after their security breach (this happened afterwards) they would have reviewed their security and improved it but unfortunately that didn't seem to be the case. There were a fair few other things in the review that were generally poor security wise, but that one is the one that stood out to me.
[0] can't find the reference I probably used, but this talks about it https://arstechnica.com/information-technology/2019/06/micro... (I think microsoft was one of the links we sent them?)
[1] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
[2] https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-p...
[+] [-] amatecha|3 years ago|reply
Third on the list: "Don't require mandatory periodic password resets for user accounts"
Just a bit below that, they specifically call out why instituting password expiration is a bad idea: https://learn.microsoft.com/en-us/microsoft-365/admin/misc/p...
[+] [-] l0b0|3 years ago|reply
[+] [-] ted_bunny|3 years ago|reply
[+] [-] teekert|3 years ago|reply
I can't remember the company but it was not a small one... The stupid thing was that it accepted the original input but simply truncated it, no warnings.
[+] [-] steve_taylor|3 years ago|reply
[+] [-] ridgered4|3 years ago|reply
[+] [-] registeredcorn|3 years ago|reply
1. Allows any input length for password, but has a limit of X characters. Annoying because it makes it a guessing game, like you were talking about.
2. Stops accepting input for password after it hits X character limit. Annoying because you can go for months thinking you're using a 30 character password, and come to find out it's actually 8. Hard to catch if you aren't paying attention to how long your obscured password is.
3. 1 or 2, but they have a rule against all special characters. I think this is supposed to be some weird attempt at preventing SQL injection?
4. 1 or 2, but they have a rule against all special characters and numbers. I've only seen this once, but I remember dropping the service after I realized what the problem was. It was years ago, during the era when something like "banana" or "pencil" was considered a strong password.
5. 1 or 2, but they have a rule against some special characters. Usually ! @ and #, or ! # % will be permitted, but other special characters will not be permitted. I suspect this is because customers "keyboard walk" with shift+123. I.e. asdf123ASDF!@# or QWER!#%qwer135 Basically, the company allows for more predictable passwords in order to prevent extra tickets being filed.
Generally, when I run into login problems, I drop my password down to 12, since that's a pretty common length; I believe it meets a minimum length for a DOD standard? If that doesn't work, I drop it down to 8. If it's still not working, then I start removing special characters and capitalization.
It's really gross that I can't expect to use a 30 - 60 character password in a predictable manner across the entire internet. In a way, I almost prefer things to be the way they are though, so I can have a better idea of which companies are strong on security, and which are either uninformed, or justify misconfigurations as "improving customer satisfaction" over minimum security policies.
[+] [-] creeble|3 years ago|reply
[+] [-] rtsil|3 years ago|reply
I always use a randomly generated string with a high entropy as answer to the security question.
[+] [-] jedberg|3 years ago|reply
Now when I'm forced to use security questions, I use long but reasonable answers, ideally ones that aren't enumerable.
[+] [-] deathanatos|3 years ago|reply
On fine day, I had to call in to the support for something or another. He's like "I need to ask for the answer to the security questions", I'm thinking "no problemo" and I kid you not, the agent asked all five questions. By the last I'm thinking "surely you can't think I'm going to miss this one?"
Edit: it also reminds me of Rackspace! If you initiated a customer support request — for which the button was in the console, after logging in, the agent would ask the security question. The answer to which … was in the same console!
[+] [-] Joel_Mckay|3 years ago|reply
1. e-mailing passwords and personal information (because customers need doxed by their e-mail providers)
2. shipping commercial beta source code to customers because someone was too impatient to learn how to package the product with a clearly labeled build script
3. shipping master x509 signing keys to random users because they are "good people" and can be trusted
4. deleting random database records with administrative privileges because it looked complicated and messy. Then tell users to pack data into document labels after destroying the key relationships.
5. goofing with passwords, then issuing a support ticket when they get auto-banned from the system
If you think an external adversary is more dangerous than someone who shouldn't have administrative privileges, than you have never dealt with real sentient liabilities.
This is why people get grey beards...
https://www.youtube.com/watch?v=uBpw1sdFu2w
[+] [-] armchairhacker|3 years ago|reply
> The password is the last four digits of your mobile number
https://web.archive.org/web/20150117203933/http://www.mysmsd...
One of the many examples in this article
[+] [-] mirekrusin|3 years ago|reply
[+] [-] jnwatson|3 years ago|reply
[+] [-] gingerlime|3 years ago|reply
[+] [-] jerzyt|3 years ago|reply
[+] [-] rany_|3 years ago|reply
It's interesting to know that this was actually a thing though...
[+] [-] danielh|3 years ago|reply
[+] [-] noicebrewery|3 years ago|reply
[+] [-] GoblinSlayer|3 years ago|reply
[+] [-] rawoke083600|3 years ago|reply
[+] [-] thenickdude|3 years ago|reply
[+] [-] fmajid|3 years ago|reply
https://pages.nist.gov/800-63-3/
They now need to be made enforceable, whether by government requiring them in government contracts, or indirectly by insurers excluding coverage if they are not met.
[+] [-] pionar|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] NamTaf|3 years ago|reply
- 8 characters
- 1 uppercase character
- 1 lowercase character
- 1 number
I used KeePass to generate a password with the default 16 characters. Specifically, it spat out: \y%/T:tMAS#1\&e9
It took me a solid 10 seconds to figure out why it was failing the first requirement: UW were only counting the alphabetic letters as characters.
I sent a screenshot to a mate in disbelief, then randomised a new PW until I got one that just happened to have 8+ letters in it.
[+] [-] Gordonjcp|3 years ago|reply
I was hoping you'd have given up on UW after that. They're a bunch of scamming bastards who will pester you endlessly to go out and sign up more people to UW.
When you see sense and stop using UW, they'll send you bills for random amounts of money for *years* afterwards.
[+] [-] chiph|3 years ago|reply
Bonus: the password reset process is broken - their customer support doesn't understand that I don't have anywhere to enter the PIN they emailed me since the website errors out. "Just enter your PIN" "Where? I only see the LASSO_1010 error message telling me to call you."
After hanging up on them after 40 minutes of frustration I decided to go create a new account. But can't because there is already an account for that address.
[+] [-] lifeisstillgood|3 years ago|reply
[+] [-] nonrandomstring|3 years ago|reply
Instead of regulating the product, you regulate the processes around it. Why?
The assumption is that users are stupid, but security people are clever. A side-effect (lemma of this axiom) is that security is for control rather than safety. Ergo - safety emerges from control. Security becomes power.
But as we see, frequently mother does not know best. The fact is that some security people are stupid (it's difficult and not the highest paying job out there) and a few users are actually very clever. Now, if the clever ones are malicious (bad hackers) you've got problems. But in reality far more clever users are benevolent and would choose to participate in a "security culture" if it were encouraged rather than imposed on them like children. It's their data.
As it stands our security culture leads not just to dismissive authoritarianism but unassailable systems that may not be questioned.
Regulation that puts much more power into the hands of all stakeholders can be a great alternative to ever more compliance and auditing imposed top-down (which is really a weak solution to a dynamic problem: security changes almost daily).
Consider a regulatory mechanism like the GDPR that allows users not just to know what data is held, but how it is protected and to request (with some force) changes to that protection.
Taken to the limit, let's call it "User Side Security" (USS), we build interfaces so that the user gets to decide their chosen security solutions (obviously compartmentalised so as not to affect any other users assets or choices).
(I feel a tremor in the Force, as if a million security people suddenly cried out in horror then suddenly fell silent.)
But this would provide the bottom-up incentive for firms to get their PII-security systems back on track without Byzantine top-down regs which I guess the industry fears more.
[+] [-] andrewflnr|3 years ago|reply
And if we can't hold people accountable for their actual products being laughably insecure, I don't see how licensing enforcement is going to go better. For starters, the question of who should be required to hire licensed engineers is the same as who should be regulated/sued into compliance/oblivion regardless of licensing, and we clearly can't do that.
[+] [-] pindab0ter|3 years ago|reply
[+] [-] Genghis_9000|3 years ago|reply
again this is just a very ad-hoc opinion, theres nothing stopping a password manager from faking keyboard inputs, or the browser from having a mechanism for supplying a password externally. that said, blocking pasting is fucking insanely stupid and shouldnt even be something web apps have control over. incidentally, the same "we dont have to concretely define anything" mentality is the same behind both issues here: allowing browser control over paste is a way of letting the app implement 1% more applications that would be impossible otherwise, while breaking stuff by ruining the abstraction; and providing a password externally would require inter application API which always fucks up because nobody has the balls to define anything concretely.
[+] [-] kretaceous|3 years ago|reply
I had to implement a "forgot password" feature in a web application. I implemented it via:
Someone could change the hash in the local storage and bypass this.Of course, I reverted to use Redis instead of local storage for this after like 3 days, fortunately with no mishaps.
I've since then made up my mind to not implement bad workarounds like this because it just felt so wrong.
[+] [-] blooalien|3 years ago|reply
(Believe it or not, this has been a far more common occurrence than it should be… Sometimes it even goes a step further by additionally limiting the length of the password to some insanely short length. "Must be between 2 and 8 characters." for example.)
[+] [-] oxplot|3 years ago|reply
[+] [-] tristanbvk|3 years ago|reply
Not sure how people end uo designing websites like that by damn. Also that Xbox HDMI cable was hilarious - I need one too because those viruses can easily enter my home network through a virus noise (like COVID) that attaches to the HDMI!
[+] [-] keyle|3 years ago|reply
I type `password123` or a range of other passwords, find a silly user using that, try every other major account providers with the username/password and I have access to that person's account?
It's also often not difficult to guess someone's email address from their username (to find more logins) since there are only a few major providers, which such silly user would definitely use.
[+] [-] a_c|3 years ago|reply