2

Recently a vendor representative told me that the reason a user couldn't log in to their site was that the password (which they check using an LDAP connection to our server) contained two consecutive dashes.

I am sorry for not getting back sooner. It turns out that the "--" in [REDACTED]'s password is causing an issue with our sanitization script ( which pulls out anything that looks like code, which could cause issues when saving it into your database table) .

How worried would you be?

  • 1
    I might be worried they can tell you a users password. Stripping strings is a common, although often weak, method of sanitising strings from injection attacks. But that said it's down to how much you think you should be worried. Only you know your system and vendor and associated contracts of support and integration – ISMSDEV Jun 22 '17 at 17:44
  • This was after regular troubleshooting had failed, and we finally authorized the user to disclose the password. It will be changed. The thing that interests me now is the existence of an ad-hoc "looks like code" sanitization script that apparently "sanitizes" user input by mangling it rather than using a reversible quote-as-SQL function or a parametrized query – user54862 Jun 22 '17 at 17:51
  • @WumpusQ.Wumbley Do you know that this is an either/or issue? They may apply both (although applying a filter on a password is a bad idea...). Your question seems a bit vague to me; We don't actually know what the approach is here. – tim Jun 22 '17 at 17:56
  • @tim I hope you're right, and it's just an extra paranoia layer on top of normal parametrized queries. – user54862 Jun 22 '17 at 18:06
3

This suggests that their sanitization practices are not very targeted. In particular, you should never have to sanitize a password. Passwords should immediately be hashed and only the hash should ever be stored. As a result SQLi via password field should be impossible.

Now normally defense in depth suggests taking extra steps for security is a good thing, even if it seems redundant. So a naive answer would be "they are being careful about security here, even if it is potentially unnecessary, so what's the problem?". The problem is that unnecessarily removing characters from passwords (presuming it didn't actually break anything) makes the passwords weaker. If their system properly "cleaned" the input both when the password was stored and when the user logged in, then the login would work normally but a password of "my--password" would presumably turn into "mypassword" before hashing. As a result, the cleaned password is more crackable than the original.

The other issue is that the way they worded it suggests that they have a sanitization script that just blindly "cleans" everything. This is really the lazy man's way to do security. I've seen plenty of systems that use that approach, and in my experience it usually means that the rest of the security isn't really well thought out.

Finally, it really is a useless security measure, and steps which make things look good without actually improving security don't help anyone. The reason why they are removing a double dash is because in SQL this is a comment, and as a result it is sometimes used as part of an SQL Injection attack. Stripping out the comment characters isn't a very effective method for defeating said SQLi attack. They need to reject such requests all together. They also better be using prepared statements properly, in which case stripping out double dashes is doubly useless.

It is certainly no excuse for a bug: that just means that they failed to properly implement a less-than-ideal security feature. Hopefully they made that comment to you as a "thanks for pointing out this bug so we can fix it". Even if they want to keep their "cleaning" algorithm, it shouldn't break anything.

  • I don't think they have any stored passwords. They just have a transient copy of the password while it's being verified. And yes, it was acknowledged that this is a bug to be fixed. – user54862 Jun 22 '17 at 18:19
  • They probably don't. You never know of course, but if they know enough to be aware of SQLi (which is probably why they are stripping out --), then they should be smart enough to use hashes. Are they properly hashing their passwords though? Obviously you'll never know without an actual security audit, but I wouldn't hold my breath. I've seen lots of people do it wrong. It is one of those cases where a little knowledge is dangerous, and many know just enough to know passwords have to be hashed, but not enough to know they shouldn't do it themselves. – Conor Mancone Jun 22 '17 at 18:26
  • I think you missed the part where the password verification happens on the LDAP server which is not controlled by this application vendor. We have the password hashes here. – user54862 Jun 22 '17 at 18:30
  • Read that the first time around, but forget it during my most recent comment: thanks for clarifying – Conor Mancone Jun 22 '17 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy