Month: June 2017

Security Fail n+1… +1

On By JohnIn UncategorizedLeave a comment

One of the things that frustrates me is when a site – or worse, a group within my own organization – tells me that my password contains characters that aren’t allowed. Or that my password is too long.

Really? So what you’re saying is that you want me to trust that your team’s developers have good security by using a weaker standard than my own?

You need to change your hash algorithms to accept unicode strings of any reasonable length – and, yes, 256 characters of unicode is a reasonable length for a password.

Also, I just spotted a maddening double-shot of security bumbling with an organization that has integrated with Google Auth. The issue isn’t that they’ve integrated with Google Auth – that’s good – but it’s that they’ve disabled the ability to use two-factor authentication therein.

They’re improving usability by using single sign-on, but increasing the attack surface by disabling a proven security feature.

Oh, and they only allow ASCII for passwords. And not even all of them.

Security Fail

On By JohnIn UncategorizedLeave a comment

Security failure: requiring that create an account with a minimum or maximum account name size.

Why it’s a problem:

  • Ham radio operators often like to use their world-unique radio callsigns to identify themselves and they are frequently four or five characters long. So they’ll need to resort to using their given names.
  • People with relatively common given names will find that they can’t even use their own name as an account name, so they resort to made-up names, or worse – using their given name along with a year of birth, creating an even bigger security risk.

Also, in your user-feedback, don’t tell them how to social-engineer your security team. A simple and vague “input prohibited” would suffice, particularly if they’re trying to include something that your software or wetware tends to stumble with.