You remind me of my bank about 17 years ago. Everyone had to have a 10-character password, exactly, and it had to include exactly 2 numbers and 1 symbol. I wasn’t very knowledgeable about computers at the time and it already felt dumb.
A few years ago my ISP pushed an update to my router that changed the password requirements, invalidating my passwords. Because I couldn’t enter the old password I also couldn’t change the password. I had to do a factory reset.
Might be checking the old password on the new password screen. Easy programming mistake to make I guess? Apply the same validation to all 3 password fields…
ISP worker here. Our chosen routers default to an 8 digit password, the first 4 are the last 4 of the mac in hex, which anyone can easily see being broadcast by the wifi network. The last 4 are a part of a unique serial number, but its just 0-9. Ultimately, if you try to brute force this default password, you need 10000 tries. It takes a regular GPU 2 minutes with hashcat. It baffles my mind that companies think this is OK.
At that time my bank allowed up to 6 digits as a password. I kid you not, like a card PIN but for online banking login. I believe the whole banking security relies on their backoffices still running on paper.
That’s what my current bank uses for the web portal now to think of it. Client number, and 6-number PIN. I guess they’re only doing this because they really trust their “unusual activity” protocols, but I’ve got a feeling they really shouldn’t only rely on those.
About as much as you punching somebody on the face could, after they punched tyouback, be claimed by you to be a preemptive punching of their face: i.e. it’s complete total bullshit.
And here we have the press from nations with heavily pro-Zionist governments and power elites spinning that bullshit into their stories whilst !World moderator’s beloved “trust gatekeeper” has their own bot telling readers they’re totally trustworthy and even in some cases that those media sources spinning the-ethno-Fascists-are-the-real-victims-here takes on their stories were they’re the ones initiating violence, are lefties.
I’m not quite sure what’s the bullshit power in this, but it’s at least square.
PS: It’s funny how me and somebody else seem to have independently come up with the same metaphor, even if I worded it in a reversed way so as not to come out as aggressive.
Hezbollah counter-attacking after being attacked by Israel, does not mean that Hezbollah would have attacked if they had not been attacked first. If your neighbour is a bully, then it’s probably best to not be a pushover.
What does lend the “pre-emptive” claim credibility, is that afterwards Hezbollah said that they had retaliated for the murder of one of their commanders in Beirut. So the Hezbollah attack was not a counter-attack, but rather an attack that they had been preparing for weeks already.
Depending on how they do their length check, this “English only” check makes sense in a way. Non-ascii letters are a pain to validate the length of (“🏴” is seven code points and fourteen bytes long, but just one “character” to most people).
I don’t know why the max length is that low (I presume it’s stored in plaintext) but you can’t expect someone to write a good password strength algorithm from a company producing the cheapest routers imaginable.
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it’s no longer your problem but the browser’s. 🦹
Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.
Edit: I seem to be getting downvoted… Bitwarden does exactly what I described above and I presume they know more than y’all in terms of security bitwarden.com/help/what-encryption-is-used/#pbkdf…
Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can’t trust the client that much.
You can hash the password on both sides to make it work; though I’m not sure why you’d want to. I’m not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?
You could salt it. Distributing a unique salt doesn’t help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.
It’s one of those things in security where there’s no particular reason to give your attacker information, but if you’ve otherwise done your job, it won’t be a big deal if they do.
You don’t hash in the browser because it doesn’t help anything.
It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn’t bad if you’re using good password hygiene with random passwords, but that sadly is not the norm.
If the end user is reusing passwords. Which, granted, a lot of people do.
On the flip side, we’re also forcing the use of JavaScript on the client just to handle passwords. Meanwhile, the attack we’re protecting against only works for reused passwords, and the attacker is inside the server and can see the password after transport layer encryption is removed. This is a pretty marginal reason to force the complexity of JavaScript.
Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
It doesn’t matter too much. It’s well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won’t get that long. If you’re really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn’t really matter.
wouldn’t you then just break it up into chunks of 72 bytes, hash them individually, and concatenate the hashes? And if that’s still too long, split the hash into 72 byte chunks and repeat until it’s short enough?
I don’t know the specifics behind why the limit is 72 bytes, but that might be slightly tricky. My understanding of bcrypt is that it generates 2^salt different possible hashes for the same password, and when you want to test an input you have to hash the password 2^salt times to see if any match. So computation times would get very big if you’re combining hashes
If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
At minimum you need to limit the request size to avoid DOS attacks and such. But obviously that would be a much larger limit than anyone would use for a password.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn’t seem like that would be significant unless your backend was poorly made.
Yep. Having to have requirements that doesn’t flow with people very well and requiring constant updates, people WILL find shortcuts. In the office, I’ve seen sheets of paper with the password written down, I’ve seen sticky notes, I’ve seen people put them in notepad/word so they could just copy paste.
This is made worse, because you have to go out of your way for a password manager, which means you need to know what that is. And you need a good one because there has been (and I’m going to generalize here) problems with some password managers in the past. And for work, they have to allow a password manager for that to even be an option. Which you then end up with this security theater.
Usually 256 bit hash is used. 256 bits is 32 bytes or 32 characters. Of course you are losing some entropy because character set is limited, but 32 characters is beyond reasonable anyway.
The eff passphrase generator has about 2.5 bits of entropy per character (without word separators). Eff recommends 6 word passphrases, and with an avg word length of 7, that’s (only) 79.45 bits of entropy that won’t even fit in the 32 characters. If there wasn’t a password length limit it would be possible to saturate the hash entropy with a 20+ word & 102+ char passphrase.
I just double checked and I have TOTP enabled for my PayPal account so it should be an option.
I just found this support article of theirs and it says it can only be enabled through their website and not through the app (why?!) so you might be running into that?
Probably people would struggle to scan the QR Code with their smartphone. I think most apps can scan it from a image but obviously this would be unsafe, especially when people sync their screenshot to the cloud.
I can 100% confirm totp exist for PayPal, because I’m using it.
lemmy.world
Newest