5 ms·
This happened to Apple too, while logging API errors (CVE-2014-1317 - in this case it was hex-encoded). Given the frequency that this occurs, I wonder if it'd
by dunham 7y ago
This happened to Apple too, while logging API errors (CVE-2014-1317 - in this case it was hex-encoded).
Given the frequency that this occurs, I wonder if it'd be a good practice to use a sentinel value for a password during testing and grep logs for it.
- patrickthebold 7y agoAnd the hex encoded version of it.
- naniwaduni 7y agobase64, too, in all four alignments.
- mikeash 7y agoMaybe we should avoid sending passwords altogether. With some client-aide code, you could build a challenge-response system that eliminates this risk entirely.
- snazz 7y agoHas there been any research into this or any companies that use it yet?
- willsr 7y agoAmazon use it in their Cognito offering.
- lonelappde 7y agoChip-and-pin credit cards use it. 2FA/Fido/Yubikey use it.
- cyc115 7y agoFido (and now w3c)'s WebAuthn come to mind
- deleted 7y ago[deleted]
- tsukikage 7y agoThere's this thing: https://trykno.com/ https://trykno.com/ As they're incredibly opaque about what they're doing, it's hard to tell whether they're part of the "get it wrong" crowd, but being incredibly opaque about what they're doing doesn't bode well.
- ifdefdebug 7y agoI used this when I was doing web apps for small enterprises in early 2000's - I sent a random string in a hidden input in the login form and had some javascript concatenate the password and the random string and send me back the username, the random string and the hash of the concatenated string. I hope I got that right (not doing web apps any more since a long time ...).
- MrStonedOne 7y agoYou would want to use a token and the string and only accept the token to look up the string that you would only accept once and for a limited time. Otherwise its vulnerable to replay attacks
- ifdefdebug 7y agoYes I think I was cashing the generated string server side for a while and checking if the string I received back had a matching entry in the cache, otherwise reject it. Anyway, it's been a long time ago, and if I had to do it again today, i would rather not roll my own.
- Someone1234 7y agoIt is possible. But much easier to get wrong than to get right. Specifically if you hash the password client side then the hash fundamentally becomes the password, and having that sit plaintext in logs is identical to the pre-hash password since both can re-played to authenticate. I believe this is still a respected/secure version of what you describe: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
- gpm 7y agoNo, having a client side hashed password sit in your logs is way better because it only introduces risk for your own service, instead of risk for every user who reuses their password on multiple services. It changes a compromise log from a widespread identify theft risk to a contained privilege escalation risk. (Provided either you, or all the other services using this scheme, are sensible enough to salt with a string unique to their website such as a domain name)
- Hello71 7y agojust "hashing the password" is not a "challenge-response" protocol.
- cyc115 7y agoThank you
- bilekas 7y agoif you can encrypt from the client side, you're always going to be able to reverse it too, its like storing the md5 of my plaintext password, just because it doesnt LOOK like my password in plaintext, it pretty much still is
- _jal 7y ago> good practice to use a sentinel value for a password during testing and grep logs Yes. I thought that was pretty common practice. We catch PII (not just password) log-leaks this way that verifying this way often enough that our developers have even learned[1] to check the searches before we yell at them when they try to take something leaky to prod. If you don't automate detection of things like this you will make the same mistake again. [1] Not being down on developers, I used to be one and still write a lot of code. Just noting a somewhat less than universal interest in compliance issues.
- raverbashing 7y agoAny recommendations of tools/libraries that help with this sort of testing/analysis?
- buro9 7y ago> Just noting a somewhat less than universal interest in compliance issues. Is there a compliance document that requires this approach? Or is it that the compliance states reasonable safety whilst handling PII and security credentials, and that it is down to the interpretation by each individual company as to what that means.
- mijoharas 7y agoGDPR covers fines for logging sensitive things like passwords. There is additional separate certification needed if you're handling any payment details (i.e. Card numbers) yourself
- madeofpalk 7y agoI guess the struggle is a) what format its being logged in and b) knowing exactly where things are being logged/stored.
- danpalmer 7y agoIt would be even better practice to use type systems that don't allow the printing of values deemed to be sensitive.
- stestagg 7y agoPerhaps users could be asked to use their password-typed keyboard when entering passwords, and their address-typed keyboard for their addresses too?
- danpalmer 7y agoNot sure if this is a joke, but iOS does distinguish between these. "Secure" text inputs get the system keyboard, regardless of the user's custom installed keyboard.
- httpsterio 7y agoSo, if I understood correctly is that having a test info like username password etc and then grepping the logs for those known test info values and if it returns anything, then throw an error?
- meowface 7y agoYes. Ideally this would be an automated process, since it'd be tedious to grep every time you're messing around with logging, and you may sometimes forget to do it. If you're forwarding logs to something like ELK or Splunk, you can set up an alert / scheduled search to continuously check for those canary credentials every few minutes.