Except when you hit a website that refuses your auto-generated strong random password, which happens to me with shocking regularity.
Happened to me two times, changed password, locked out, had to reset. then while logging in, I noticed their requirement of 12 characters, at next reset used 12 characters, & did not get locked out.
Ah, now I understand why I got those downvotes. What I meant by "OK" was that it would "work". It wouldn't exhibit the behavior my parent comment was describing. Not that it would be secure or good practice.
The initial signup also checked & showed that toast. But the 90 day reset page did not.
But no one is going to get fired or held back for choosing those 'enterprise' tools. They've spent a lot of money, everyone has a checklist, and people move on, even if there's a breach. And some jr might have pointed out "hey, this open source toolset does this, but is kept up to date and has found 47 things our scanner didn't find" and this jr will likely be ignored.
It’s maddening.
Maybe there's a clever trick I'm missing here.
Of course any proposal to ever hold a programmer accountable for literally anything is always unpopular on HN, for obvious reasons.
Engineers should only be held accountable for decisions they made personally. The unfortunate reality is that, a terrifying amount of the time, terrible decisions are handed to engineering teams as required implementation details from managers, executives, product directors, etc. So should engineers be held criminally accountable for their product manager demanding MD5 hashes on passwords?
Do you think the guy signing off on a bridge or power station design gets pushed around by “product managers” demanding shitty or cheapskate design or construction?
You were arguing that the specs or decisions made above their pay grade forced the software engineers into a dangerously faulty design which they dutifully created and shipped.
Of course management should also be held accountable, but until engineers are forced to have some skin in the game they will continue to be as pliable as wet noodles.
Consider this: who better to blow the whistle on management than an engineer who knows they've been given an illegal order?
What you're asking is for an engineer to be stuck in a place of legal culpability if they do the work, and to be fired if they don't. Added bonus: you mention whistle blowing, but who the hell would they whistle blow to?
If there's a proper industry or governmental group to blow the whistle to, that will also see the engineer financially compensated until such a time as they find a new job, then fine, it's fair to make engineers culpable. Otherwise, you're just making engineers suffer for the bad decisions of those made above them, by making them either legally liable, or risking their jobs.
You're looking to now make it so that there's a punishment levied on the developer, who has no more power to say no than they currently do. You want them to say no, but all you're doing is making it more unpleasant for them to not do so; you've done nothing to make it easier to do so.
I guess we just fundamentally don't agree on how power dynamics effect these types of scenarios.
Right now, the conversation goes, management: "I want x". Engineer: "X is insecure, we should do y instead". M: "Y will cost us X more than x, and it's never going to matter for us, anyway."
This puts the engineer in a position where they need to argue and justify the cost. Compared to "Sorry, I can't do that; it's illegal and I'd go to jail if I did that and was found out." Now the engineer doesn't have to justify anything. The law isn't a burden on the engineer here, it's a shield.
Yes, there are still some scenarios in which management insists. In my limited experience, that's in gray scenarioa where it's arguable whether the law applies. But the point is, it's much easier for an engineer to argue whether the law applies, than whether it is worth the money.
I think you can see these effects in the lengths companies go to protect healthcare data (hipaa) vs any other random personal data.
The equasion should be, for management: "Y will cost us X more than x, but if X is hacked we will get taken to the cleaners"
For the actual engineer to be held responsible you would have to add a formalised approval process, so that its clear who signed what off. Inagine you signed off on something, and then changes were made without your knowledge - that much easier to do with software than a bridge.
The big difference is that companies need professional engineers. Professional approval on certain things is required by law. I'm not sure that would be a good idea for software, but that is what makes the system work for professional engineers.
Presumably there would be repercussions at the government level if a company repeatedly demanded engineers do things worthy of stripping their licenses though, no?
The individual engineer doing the work needs a license, but the company itself also needs a permit to practice. The permit must be held by an engineer, who is personally responsible for the engineering that occurs under their permit.
So, the permit holder needs to worry not just about their own ethical behaviour, but that of all engineers in the company. They are incentivized to ensure the company will hold the public safety paramount, or to walk away if they cannot (thereby leaving the company without a permit).
If the company has a pattern of misbehaviour, it may be difficult to obtain a permit.
So, yes, we agree, if there are repercussions for a company regularly breaking the law, then engineers can and should refuse work that has negative legal or moral repercussions. But in the world of tech, that's not the case.
I personally believe that you, the software developer typing in the code, should hold yourself personally accountable for what you are typing in. You might also be designing what you type in, or even setting the requirements, but it might be other people. Regardless, you are making the software come into being--you're the one coding it and pushing it to the repo, so you should set the standard of what is acceptable. This "well, boss told me to do it!" rationalization and blame-shifting is how we get dangerous and unethical software.
And, yes, I have quit software jobs where I was asked to write software I considered ethically questionable, and failed to change the boss's mind.
No, I am suggesting that there is significantly more grey area between your moral highground and reality.
> I personally believe that you, the software developer typing in the code, should hold yourself personally accountable for what you are typing in
Yep.
> This "well, boss told me to do it!" rationalization and blame-shifting is how we get dangerous and unethical software.
It really is a strange world that, when corporations are attempting to turn profit on illegal behavior, it's the meaningless bodies-in-seats that we're trying to hold accountable.
I am, and have been, repeatedly, suggesting that the lowest level cannot be held accountable without holding the rest of the levels accountable. Jailing engineers for doing things their companies demanded of them is ridiculous if you're not also jailing those doing the demanding. I'm kind of shocked this isn't painfully obvious.
> And, yes, I have quit software jobs where I was asked to write software I considered ethically questionable, and failed to change the boss's mind.
Congratulations, that's a level of privilege lots can't afford.
Please login
Username: __________
Password: __________
(Not that I can read German to the standard required for understanding laws and looking it up for myself; I can just about manage tabloid newspapers…)
It should still be consistent with registration/login with things getting truncated, but I think this is also the default in PHP if you are using password_hash() today. Is that a security issue?
https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
I don’t think it’s “a default”, it’s a fundamental limitation of the algorithm.
Specific bcrypt libraries could implement length-reduction by default though.
Or better yet, pick one of the other algos with better limits and protection like Argon2 or Scrypt.
Iterated password hashing algorithms like bcrypt [2] use a parameter tuneable by the site operator that drastically varies the computational cost of calculating the hash, so a brute force attack on the hash could be required to use orders of magnitude more computational power to crack. The tradeoff is that it will make users wait longer to log in, and (might) incur additional operational cost to the site. This is why it's a tuneable parameter: Up increases security at the cost of user delay and operations.
In theory. In practice, the user delay and operational cost are also proportional to the user's password length, which you don't control. Observe, the leak. This can cause wildly varying response times for authentication attempts, and opens your authentication system up to a DoS attack. The only reasonable solution is to put a small cap on password length so that the longest passwords don't take more than 2-5 times as long to compute, as per each site's tolerance of variance.
So why does the runtime of the iterated hash function depend on the length of the password? In each iteration the user's password is joined to the previous iteration's hash, and hashed together to get this iteration's hash. The runtime of any hash function is proportional to the length of the data fed in, the data fed in includes the user's password, thus the runtime of an iteration is proportional to the length of the user's password. So the runtime of the whole iterated password hash is `O(Iterations * PasswordLength)`.
There are various schemes one could come up with to change the time to `O(Iterations + PasswordLength)` ~ `O(Iterations)`, such as concatenating the first hash of the user's password instead of the password itself on all successive iterations, so all iterations but the first are independent of the user-chosen password length. There could be some security/entropy-based arguments for avoiding this solution, though I don't know what that could be.
It's fine to truncate the password (though ideally you don't do it at a super short length).
The issue you are replying to is referring to when a site doesn't do it for both account creation and login. Which is a bug. A stupid, hard to detect, hard to explain, likely never to be fixed, bug. That only affects people trying to be secure.
Regretfully Enpass doesn’t store this field nor the rest of the complexity rule as part of the password entry. The next time when password has to be changed you have to figure out the underlying complexity rule again.
hypothetically it's "ok" but c'mon..
And in practice this effect can be exaggerated when people don't use random passwords but must actually choose a password they'll remember - because what they'll actually do is choose something easy and then shove a symbol in there to meet your requirement. You may well allow 30+ different symbols, or even more, but the users will invariably pick one of a dozen or so that were easiest to reach on their keyboard and they may learn to be shy of characters that sometimes "don't work" such as quote marks and any local currency symbol even if those are easy to type.
They might write it on a flipboard next to a window.
https://grahamcluley.com/plymouth-passport-offices-pitiful-p...
Hi Westpac.
But yes, at that point all you can do is either complain to the website purveyor or vote with your feet (if the latter is an option).
"Your password is too long!"
"Your password uses special characters!"
... they are not only incompetent to write code which handles passwords, they have been so misinformed that they are an outright liability. They need to relearn everything they currently know on the subject and start over. Few things in the technical world instantly convey such utter anti-knowledge as the presence of either or both of those error messages in a codebase.
Obviously for a gigabyte long it's a bandwidth and hash-computing issue :p
Yes, that’s why you put in limits which are way beyond reasonable passwords but way below that. Say a few hundred or thousand bytes.
Also worth consideration: most of these work on bytes, probably utf8. A user wants to be cute and put emoji in there, that’s 4 bytes a pop. So depending how the system counts them, “hospital plane” might be considered 2, 4 or 8 characters.
But wait! Group emoji are concatenation combinations thereof, you can have a single multi-character emoji which is composed of half a dozen codepoints, and two dozen bytes once encoded.
https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...