Some hackers DoS the code. This guy DoS’s the corporate process.
Some hackers DoS the code. This guy DoS’s the corporate process.
Nobody going to admit to being the pigeon? Because that’s me.
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. It just means the attacker can send the hash instead of the password.
With comments like this all over public security forums, it’s no wonder we have so many password database cracks.
There’s a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That’s impossible to break due to thermodynamic limits on computing.
The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.
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.
Scrypt has the same limit, FWIW.
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.
If it’s compsci, then it doesn’t need to be bare metal. It should be a language that’s good at demonstrating abstractions. Java wouldn’t be my choice, here. Elixir would be a good one.
You might want bare metal as a prereq to an operating system course.
If it’s software engineering, OTOH, then yes, a bare metal language has a bigger place.
Valid, but if it needs to be decided, then there should be something concrete scheduled to do that followup when people are back in.
GNU HURD remains ignored.
Libertarian Socialism has little to do with US libertarians. The term was openly stolen for the Right. The intellectual history is completely separate.
Murray Rothbard: "One gratifying aspect of our rise to some prominence is that, for the first time in my memory, we, ‘our side,’ had captured a crucial word from the enemy . . . ‘Libertarians’ . . . had long been simply a polite word for left-wing anarchists, that is for anti-private property anarchists, either of the communist or syndicalist variety. But now we had taken it over… "
While it’s true that lots of libertarians prefer Linux, the first ancap I met in an online forum was a Romanian-born Christian living in the US, was so fundamentalist that he was actively looking for a church where men and women sat on different sides of the pews, loved Microsoft, and hated Linux. He also had a habit of changing the definition of words in the middle of debates. People found him completely infuriating.
Pi Pico SDK does. Well, the version for debugging symbols, anyway. Regular executable is .uf2.
I’ve actually met him. Pretty chill guy, but is completely confused by his Internet fame.
There will likely always be a job for someone who has good Perl knowledge. There’s no good reason to start a new project in it, though.
Eh, it’s a language that rewards deep knowledge. I like that. But it’s not coming back.
As a Perl developer: not going to happen.
IIRC, the original reason was to avoid people making custom parsing directives using comments. Then people did shit like
"foo": "[!-- number=5 --]"
instead.