Fair! I did think about this a lot. Initially, I also thought "8 characters of any kind" are fair enough. Then read a lot and decided a bit more security would be good. But honestly, given what you wrote, I did find myself happy that I had an account before this security measurement. So I guess, I'm of your opinion.
However, the app does not enforce lowercase/uppercase. It uses Laravels uncompromised() function which I think makes sense. It checks against https://haveibeenpwned.com/Passwords.
I'm happy to discuss length! But I think the uncompromised makes sense. But happy to hear any arguments!
If it makes it harder to register, that is still an argument and must be discussed against the argument of security. I'd love to hear other peoples thoughts here since security vs usability is always a complicated thing.
Don't make your password requirements less strict. Don't encourage people to use weak passwords that are likely shared across sites. That leads to pain and suffering over the long term.
If you want to reduce friction for people who don't/won't use a password manager, provide a passwordless option like a login link that is e-mailed to them. Yes, people will likely complain about "your service is supposed to be my email, why are you requiring an e-mail to login", in which case they should be using a strong password.
To the person requesting weak passwords: Just set up google or firefox password password manager, it will auto suggest a strong password on the registration page and save it for use across devices. There is zero reason to be using the same password across accounts, and a lot of reason not to.
Attackers do actively try passwords you have used on other sites to try to compromise your accounts elsewhere. This happens when services leak passwords or password hashes. If your password is short and lowercase, it really doesn't matter if only your password hash has been leaked, it might as well have just been the password itself. This is the lowest-hanging fruit for attackers.
Thanks for your opinion. I appreciate it. I think that makes a lot of sense.
I also like the idea of passwordless, I'll definitely have a look at that!
There really are only two dials you can turn to increase the security of a password, and that's length of the character set (the characters that the user can use in their password) and length of the password itself.
People should be using a password manager, then they can set that to 100/200 characters. Even if all lower case, it will be unbreakable (assuming a modern/secure one way hashing algorithm, and the password manager is truly random.).
If they are not using a password manager and use something like `waterfall!X` (because you enforce a special character and capital letter) you haven't actually increased entropy by that much, compared to a longer password. Them making up a 100 character password will almost guarantee more entropy than a short password they make up like `waterfall!X`
Yes, I did read up a lot about password security the last few years. But still, I'm worried a very secure policy restricts people from registering at all, see case above. What would you say is a good compromise?
Another thought I have discussed a lot is, this app is not something critical. It's not online banking, it saves very little about you (as little as possible), etc. - so what does this say about the compromise? If an account was to be compromised, an attacker would only have access to the todos, music, notes of a user. Now, todos and notes could be very telling, but I'm unsure about how much of a responsiblity I have as an admin to save users from this? Do you know what I mean?
Yeah I understand. I think my point is don’t add any other friction to the password strength other than length. If you want more security increase the min length, if you’re happy with less, lower it.
I’d personally have a 12 length password enforcement, a password strength meter and nothing else. Possibly less if you introduce 2fa.
I wouldn’t really call that AI slop. Some people just write longer posts because they’ve got a lot they want to get across, and you can usually tell it reflects their own opinions and what they think matters in the discussion. Actual AI-generated stuff tends to come off more generic and lacks that personal angle.
At least we have a pardon czar now. So many people have been coerced into committing crimes, with said coercion taking many different forms, there needs to be mass pardons across the board.
Python's absolutely fine to use for a "serious backend thing" at a telecom firm.
It's a language that attracts casuals, but that does not mean it's incapable of being used for serious software engineering. The only scenarios where I wouldn't use python for a "serious backend thing" are scenarios in which there are dramatic cost/performance/etc consequences resulting from the overhead of using python which would be substantially reduced if using $lowLevelLanguage. Even then, there's always the option of outsourcing specific units of functionality to say, c++, anywhere the performance difference actually matters.
I would say that for the vast majority of use cases, acceptable performance could be easily achieved by simply writing better python.
Writing this reply brought to mind some absolutely atrociously inefficient ORM code I encountered in a python codebase recently. If you don't have an understanding of how to utilize SQL efficiently, it doesn't matter what language you're using to construct the SQL queries, the software engineering equivalent of warcrimes is possible in any language.
Location: Vancouver, WA / Portland, OR
Remote: Highly Preferred
Willing to relocate: I'd prefer to stay in OR/WA, but can compromi$e
Technologies: Python(Django|Flask|Fastapi), Javascript/Typescript, CI/CD (circleci|github actions), Testing (pytest|jest|etc), Docker, Nginx, Linux (prefer debian variants [although I allegedly have code in redhat]), ... pretty much everything both code&infra that goes into serious web app/api, while also ensuring best practices are followed.
Shill: I'm working on something called open2fa that I want to have launched within a couple more weekends max, I think it's pretty cool. https://open2fa.liberfy.ai/ here's how it works.
>We didn't disqualify anyone for using AI, we disqualified them because of their dishonesty. If you can't trust someone in an interview, how can you trust them in a remote environment?
Radical honesty has been a core cultural component to many a strong team, I'm glad to see somebody else mention this. There seems to be something unique about the relationship between codering and the concepts of transparency, honesty, and truth more broadly.
Or maybe that's just a consequence of version control :)
It’s a fundamental part of (reliable) engineering. Many a person has died historically when in ‘harder’ engineering someone was hiding things, and someone being able to acknowledge their lack of knowledge is key to not getting into that state - or being able to progress/grow at all, IMO.
Chernobyl being one prominent example.
At least in a field like engineering where actual successful results/working output matters, anyway.
There are other fields where the same dynamics are not in play.
One cannot solve (or even avoid) a problem that one refuses to acknowledge exists, after all.
The relationship of capitalism to truth is very significant as well, or maybe 'value generation' would be a better term to use here than capitalism.
Or as I usually phrase it, 'money is allergic to lies'.
Say you have an organization that is producing a product/service that provides genuine value for its users, and have a team of talented, hardworking people. Any factors related to the operations of said organization, obscuring those factors from the value producers can only lead to less effective operation overall, as the producers have less/lower quality/false information to work with.
"I don't feel like this is workplace appropriate" does not violate the 'radical honesty' principle.
At least internally, anyway. If your objective is to make as much money as possible, you probably don't want marketing to be radically honest LOL
>There seems to be something unique about the relationship between codering and the concepts of transparency, honesty, and truth more broadly.
And what is worse than lies, is self delusion, even if honest. To nit pick on radical honesty, my observation is that most people won't tolerate it, plain honesty appears to be the sweet stop inmost cases.
Why not just allow users to use lowercase a for their password? This would have helped me register for the website.