191–200 of 327 posts
Want to DDOS somebody? Try their password incorrectly three times. Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.
I just close and reopen an incognito window and voila, no more rate limiting.
Earlier quoted context omitted.
I've lost count of how many times I had to "fix" broken sites by editing the javascript manually client side.
What's your process of editing client side JS? Is there some method to capture scripts before they load so you can make your modifications?
Say there is a function named ‘verifyPassword()’ you can simply run ‘verifyPassword=function(pass){ return true }’
Earlier quoted context omitted.
> I've actually had one company reach out to me after making it on the list and they made their password rules less dumb. That’s a huge win! My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?
> My pet peeve is sites that block pasting Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true). Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.
Passwords, on average, have around 40 bits of entropy (or 0 if they're in any existing list, and some lists are 500M strong) so don't us pass words. Also, TLS is MITM-able (the CA system is one giant backdoor, CT doesn't prevent MITM attacks) so you're password and authenticated token can be captured and your account can be pwnd. Don't use pass words. Use mnemonics to derive public/private keys and use authenticated…
Let's take the "insufficient serial entropy" as one very clear example. That was a Brown M&M and not an actual technical concern, but you haven't understood that at all and just linked it as part of a claim this is "Security Theater".
Several of your links supposedly about "HTTPS snooping by Governments, Employers and Hackers" aren't about HTTPS, or even TLS, or even the Web PKI, but instead unrelated "certificates" of one sort or another than you apparently didn't understand weren't the same thing. For example the Apple Insider article is about Apple's iPhone application signing.
And then your "solution" ends up relying on all the same infrastructure you've wasted slides decrying as subject to MITM, including both HTTPS itself and OS-specific code signing.
Get out of here with that Coiner nonsense.
My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York. I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figu…
And of course then logging in doesn't work at all. It took me days to figure out what was going on.
I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).
This is slightly different but webex makes me change my password every 30 days... It's ridiculous...
It makes sense to change credentials periodically, but the policy of 30 days for humans doesn't work because the humans aren't realistically going to remember new credentials every 30 days.
If you have Let's Encrypt, the default setup (Certbot) will change the key every time it renews, typically 60 days, but you aren't expected to remember the key it's just data for a machine to store somewhere, so there's no practical problem and it defuses some risks (e.g. bad guys get hold of old backups). So the idea of rotating credentials like this would make sense _if humans weren't expected to remember them_.
Earlier quoted context omitted.
> I've actually had one company reach out to me after making it on the list and they made their password rules less dumb. That’s a huge win! My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?
> My pet peeve is sites that block pasting Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true). Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.
Hi, I made this. It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad. It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb. So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.
Would you allow ascii characters under 32? Or would you considere it a dumb rule to disallow them?
From a usability perspective, if someone manages to accidentally enter some dodgy control codes, and then can't log in on other devices because they don't know how to enter their password, it may be problematic.
Personally I think if a user chooses to put control codes or emoji or the unicode symbol for 1/2 as a fraction in their password, they're entirely welcome to have that but they shouldn't be surprised that when they want to log in they have to enter the password with that in it.
Ultimately, it depends on the expense of the support request that arises when users screws up and needs to reset their password - if it's too expensive it may be worth excluding the really exotic characters.