Brain waves are approximately in the 1hz to 100hz range. While smartphone waves are much higher frequency. AC however is 50/60hz depending on country. Maybe I'm overly cautious, but I have a thick wire that runs right next to the natural spot for my pillow I very intentionally put the pillow on the other side of the bed.
I’m afraid that deep sea mining operations are motivated by greed. It will not be easy to get sustainable solutions out of this and not only deep sea creatures will have losses…
By disabling user input the application security actually gets worse. Users that can’t copy e.g. passwords will use less complex passwords to overcome the trouble of typing in their initially good passwords. But also user experience is degrading when applications enforce complex input and users generate that input like a chad as they should. But now they cannot paste…
I'll add to that systems that require particular characters to be used, like "must use capital, number and special character". I prefer to generate longer passwords but using only regular characters because I find it easier to type on the occasions I do have to do that.
Even worse, there are some that restrict what kind of special character you can use. So even when I've generated one I still have to edit to remove one particular character.
Would it really be that difficult to display password strength and say things like "use more characters, e.g. you could use four words".
Even Apple was so annoyed at this themselves that they actually went for a full open-source open-for-contributions GitHub repository at https://github.com/apple/password-manager-resources to get around these issues.
> Many password managers generate strong, unique passwords for people so that they aren't tempted to create their passwords by hand, which leads to easily guessed and reused passwords. Every time a password manager generates a password that isn't compatible with a website, a person not only has a bad experience but a reason to be tempted to create their password. Compiling password rule quirks helps fewer people run into issues like these while also documenting that a service's password policy is too restrictive for people using password managers, which may incentivize the services to change.
You don't even have to make a single line change to your backend to fix this. You can fix this entirely on the frontend by just applying a digest hash on the password before sending to the backend for proper password hashing. This way you can even support "unlimited" length password.
That's a very much backwards incompatible change: password that used to work no longer does.
Sure, just put your 500M users through a forced-password reset.
Theoretically, it might also lead to weaker passwords depending on the hash size (that's how you support unlimited lengths by transforming a larger space into finite one) or any issues with the hashing algorithm uncovered in the future.
One thing to keep in mind is that the hash actually becomes the password, so I can imagine plenty of buggy implementations where a developer does not do what you advise ("proper password hashing"): "hey, it's already hashed, I can just store it as-is".
Limiting characters can also be a feature, so users can't use emojis in their password (this is so fun), to realize later they can't login, because they don't know how to input emojis from their desktop computer.
Hopefully passwords will be gone soon (at least that's my hope).
Don't get me wrong, it's a stupid limitation indeed -- but sometimes decisions like these are meant to stop users from doing stupider things :)
I'm no fan of oversimplification, but Apple's audience is everyone, not just power users. In that case, I'd prefer having advanced options surfaced to me as "advanced" so I can do what I want, but leave the simple experiences for the simple folk.
You might have half a point about emojis, but that's not what Apple is doing here.
Is there a reason I as a Swede should be limited from using my full native alphabet in my passwords for example?
As an example, you know how people sometimes suggest using a short sentence as a password? Here's a phrase in a local dialect, which means "and in the river there's an island"
Å i åa e ä ö
Notice how only 2 of those letters are available in ASCII.
ASCII only is not a feature, and I honestly doubt anyone would try to argue that it is if this was about any company other than Apple. Try to look past the "who" and focus on the "what".
Aren't those keyboards usually readily switchable with a standard US keyboard layout (e.g., in Windows, MacOS, or Linux)?
Do you have any direct experience with this?
My point is that 7-bit ASCII underlies virtually all other keyboard / character encodings. Among the few cases where it doesn't (e.g., IBM mainframe EBCDIC, independent of ASCII), the principle encoding remains the Latin alphabet, and can readily be converted using standard system utilities.
They aren't readily switchable unless explicitly configured to be, and yes, I am speaking from direct experience.
I get your point, I am just saying that it is not universally true, even if my example is a stretched one (Cyrillic keyboard users always configure Latin-based layouts too, but it's not a default, and it's easy to forget esp if you install from a fully live env configured with both).
If it's still not clear, you can end up on a login screen with an ASCII password you can't type in, especially so without the GUI.
The worst I've seen have uncommunicated password length maximums—but don't error when you exceed them. Instead, they just truncate your password, but only on creation. When authenticating, they don't truncate, so your password you just made with a password manager is "wrong".
Spotify did/does this. Made canceling my free trial really tricky, because I needed to log in again to do so.
That one irks me too... When I built an auth/rbac app previously I did make Max length configurable and it would display a night if set. I set a hidden hard limit to 1k only to reduce attack surfaces that would only display and error if exceeded.
Default was a min-length of 15 as the only requirement with the default hint of "try using a short sentence"
I also had optional use of zxcvbn and haveibeenpwned checks during new passphrase creation.
I really wanted to open source the application but couldn't get approval to do so.
It was a pretty nice little simple auth application that issued RSA signed JWT to configured applications. It was interested into a few internal apps as well as for clients that didn't have something like azure ad, okta, etc. where we wrote bridge apps for auth.
If I had my configuration doc, I'd probably recreate it exactly, but with a Rust backend with HTMX instead of C#+react.
The date store used SQLite as a KV store, with simple methods for access that allowed an exception later for the values. Also wrote support for PostgreSQL and MS-SQL so they could be used where available.
Spent a lot of time on same defaults, hashing and encryption along with required configuration options for a few clients.
Aside: more devs really need to better understand public/private key generation and usage... Like not using the same keys for different environments.
Even worse, when the password has an arbitrary length requirement of 20, but the site doesn't tell you and just cuts of any trailing characters exceeding the requirement during account creation.
You have no idea how long it took me to figure that one out.
Slightly easier to figure out but no less annoying is when the maxLength attributes on the password fields for the two forms (create account and login) are different.
Even worse, some will simply arbitrarily silently truncate the password. But not everywhere! The sign up page might silently truncate and then the actual login page might not.
What happened to me once is that a long-time password of mine got truncated as the website lowered it's maximum password length, and the login page didn't truncate, so my full correct password suddenly stopped working. The pain.
Several comments mention passwords getting silently truncated by input maxlength. FWIW my extension provides a visible warning when this occurs: https://underpassapp.com/StopTheMadness/
Are you referring to 'security questions' where the user must choose from a predetermined list? A predetermined list which is often questions whose answers may be know to close attackers (first school), not applicable to everyone (name of first pet), or anglocentrically blind to worldwide cultural diversity (mother's maiden name). I hate that so much.
Providing a list is fine as long as they let the user type their own question if they want to. I cannot trust the security of a single one of their crap questions if I were to answer them honestly. However, if they let me type my own question, I can absolutely guarantee it.
For my own applications I typically require only three rules to be kept, two of which most users will never even encounter, the password must:
1. be long enough (e.g. 8 characters or more)
2. not be in the list of 10k most used passwords
3. not simply reuse words present in the username, email, birthday (if my application knows about it)
This keeps it open and only interferes with truly stupid (aka insecure) password choices.
Additionally I like to propose 8 passphrases to the user so they can choose one of their liking with one click (this also serves as a proposal what a good passphrase could look like).
Good, except min 8 chars is not safe at all. Don't approach any semblance of security before min 12 chars. Min 14 is when you get into real security. The increase in entropy is exponential with password length, so security increases quickly after this.
That is why I wrote e.g., actual length can be tuned to fit the purpose of the application. If there is really sensitive data or attackers gain privileges that could wreak havoc in the wrong hands I'd probably go with 12. If an attacker would gain next to nothing I'd go with 8 for comfort reasons.
This is in addition to other mechanisms of course, like rate limiting password attempts, fail2ban, salting, peppering, chosing the right hash, proper database separation etc.
The goal should be that only an attacker that has a copy of the database could profit from too short passwords, and only if they get the salt and pepper correct, to avoid rainbow-table-attacks.
The entropy doesn't increase exponentially if my password is just N copies of the same character or phrase, it only increases linearly.
Minimal password requirements allow people who know what they're doing to do the right thing. If you want to stop people who don't know what they're doing from doing the wrong thing, it will take a lot more than just length restrictions.
All that users do when they get hit with restrictions like that is repeat their password again, or fill it out with exclamation points. Not a lot of entropy getting added.
I miss the old days of youtube when they had no restrictions. My password was x for ages. I think the only thing I use which still allows short passwords is my apple system password which thankfully is still three characters.
Shout out to forms which error out with "Password too long! Must be at most ten characters. All from this subset of ascii". Which seems especially popular with banks.
I suspect, somehow, that this is stupidity with the bank's processing core systems, which ... things are weird with financials.
They buy someone out, and now there are two systems. Glued together with duct tape. Then they release a new web product, or mobile app, or whatever, and that gets taped on too. Duct tape and spit all the way down, with everything eventually limited by the most broken part (if you're lucky).
Very frustrating that any place where I can store code has way more security than what's more important to me: place where I store my money. Financial companies still using SMS for 2FA!
You want to have weird password rules? Fine. Please make some standardized meta tags my password manager can find so it generates perfect passwords every time. Bonus points for a well-known URI facilitating touchless password rotation.
I'd be fine with storing the password policy in the password manager, and having it generate based on that policy next time.
And having all sorts of weird stuff in a password isn't necessary, so neither is the policy. To top it all off, many of the sites obsessed with password quality actually limit password length. Why?! You are comparing passwords hashes and storing them as hashes, right? So the length shouldn't matter.
Allow passwords of effectively unbounded length, set a reasonable minimum length, and don't obsess about password 'complexity'.
And for the love of all that is good, don't eff with paste.
(Those of us who know, already know. I'd like to say that we all know here.
But if a reader does not recognize "correct horse battery staple", then you're obliged to click the above link -- you're one of today's lucky 10,000![1])
I have multiple Google Accounts. One of them, I want to remember the password. The others, eh. I just want to copy paste. Doubly so for practically anything else. I wish they'd just let me copy paste.
I have developed a maybe irrational fear of space in strings such as passwords and paths. It always scares me when people use spaces in either case.
For passwords I have to actually remember and type in (os login, password mgr evs) I expressly use a short sentence, often with spacing and punctuation. Sometimes an intentionally misspelled word.
In addition, they will probably also still try to copy to clipboard first, since they probably don't use that interface often enough to remember its special rule.
I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing.
Firefox and Chrome's built-in password management tools would never accidentally enter your credentials on a lookalike site, but you very well might.
That's all great, but then there are the times when they don't offer to copy the credentials where they should. Maybe the "correct" URL was too narrowly defined to be useful, or was taken from the setup context and is otherwise wrong for regular usage.... maybe the site changed their authentication process... etc. In the end, all of this tends to defeat the very resistance to the manual entry impulse you describe. If these password manager entry systems worked more flawlessly, your point would carry more weight... but having to defeat the protection your assertion relies upon is commonplace enough in legitimate purposes that it may well be nullified at all times.
In the end, as long as a site is going to use username/password authentication there will always be the need to educate users about what to expect sans the aid of tools.
> I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing
This is like advising that glass sidelights be installed next to the vault door.
I agree, young people don’t invest in others anymore. It has emotionally become a consumer world. E.g., try getting some volunteers at your local sports club.
Fuck ‘content creation’ on mobile phones.
I like mobile phones for two reasons, 1. because it is a phone and 2. because I can use it for authentication stuff.
The rest is all focused on consuming and giving away your data.
- Short and grabs attention: Single paragraph - good.
- Super clear on who you are: A Nigerian prince obviously
- Value prop for the receiver: Millions of dollars!
- Has a specific ask: Access to your bank account, easy
The key point here is the credibility part. The Nigerian prince has no credibility. If you are approaching someone looking to solve a problem and you demonstrate competance via an extensive Github profile / blog your chances of a response are enormously increased I'd have thought.
I've read (in Freakonomics I think) scam emails often have deliberately low credibility to "improve" the quality of warm leads.
High credibility emails that deceive digitally savvy people can create a lot of warm leads who take expensive resources in phone calls and human interaction, but often fail to convert to paying victims. At some point down they funnel they realise it's a scam.
Low credibility emails generate replies from less digitally literate people who're easier to convert into a paying victim when they reply. The response rate is lower of course, but sending another email is free.
Some do, others ruthlessly murder their rivals to get to be prince (in the sense of ruler, not 'son of the king'). Others have to win a power struggle to maintain the accident of birth that put them there.
They're a prince. Of course they have credibility. Of a country as populous and gifted in natural resources as Nigeria, even!
But I get your point, and eagerly await my spam with deposed princes' githubs profiles not stolen from MIT licenced projects, and blog photos not written by GPT and illustrated by DALL-E.
Perhaps what we need is a credibility coin, based on blockchain. Or a national ID card system. To prove I am who I am. As without it, I am not.
You also need to end with "God Bless" or similar - it wastes less time on the scammers part because people who fall for that line are more gullible[1].
[1] Can't remember where I read it; was a short study on how skepticism is inversely correlated to getting scammed. A different reading some years later showed that religious believers have lower skepticism when dealing with other believers of the same faith.
You just have to pretend to be of the same belief as the mark.
I once tried to help my mom use the computer (around 2010). It took maybe 20 minutes before we called it a day and split ways heated. After reading this I feel ashamed.
You are talking about a larger fundamental problem; code quality.
This library can be a way to handle errors just as the try/catch block is. If agreed on within the team ofcourse.
