0

I have an issue where our app had an app scan issue. The application is using GET to retrieve info for a user profile page (written in HTML/Javascript). This page has the user's security questions and answers, but the answers are in plain text in the raw response.

What is the best way to handle this? The user needs to be able to edit the answers (they are masked out) but we don't want to be open to attack, of course.

Is the best choice to use some fake text to show in the box and then check that fake text on save? This option doesn't show the true number of characters for what they originally typed in. Is there a better method?

I checked this security.stackexchange question but the answer doesn't say what method is best for this scenario.

  • 1
    It sounds like you are sending the security answer back in the HTTP response. Why? – Jedi Jul 11 '16 at 14:37
  • @Jedi this is in an edit scenario, the user wants to edit their security question answer, for example. The requirement is to see the masked field with data in it to show that they had previously set an answer here. – JasonWilczak Jul 11 '16 at 14:40
  • @Jedi yeah, the business req was to have it show that there was an answer previously (i didn't write this code) in a masked input box. AppScan is upset that it is returned in clear text. – JasonWilczak Jul 11 '16 at 14:47
3

Is the best choice to use some fake text to show in the box and then check that fake text on save?

Yes, this sounds like the way to go.

This option doesn't show the true number of characters for what they originally typed in. Is there a better method?

I would see that as an advantage. I would see little benefit in revealing the number of characters in the original answer.

I would also be tempted to store these answers in my database using something like bcrypt. This depends if there is any requirement for the answers to be verifiable by a human (e.g. in a call centre to authenticate the user). If not you could uppercase the answer and strip all non-alphanumerics. This would allow correct answers to be easily entered by users, with a small increased risk of hash cracking by an attacker (e.g. if they enter "Foo Boy's School" as opposed to "Foo Boys School" because it would be stored as FOOBOYSSCHOOL). Iterations could be increased though to account for this as this information should be used rarely. This would mitigate a situation where your answers table is exposed to attackers where they could then use them to carry out a password reset.

Again, this depends on how any password reset mechanism works for your system and your level of acceptable risk.

  • Thanks! We encrypt/decrypt the answers and passwords, as far as storage goes so no issue there. This is mostly on the best approach for our presentation layer edit functionality. Thanks again! – JasonWilczak Jul 11 '16 at 14:58
  • You mean you can retrieve passwords by decrypting them @JasonWilczak? – Jedi Jul 11 '16 at 15:23
  • @Jedi i can't speak to it completely, but there is a security component that is at an enterprise level that manages secure data storage and verification. – JasonWilczak Jul 11 '16 at 19:16
  • @JasonWilczak ideally you'd irreversibly hash the passwords. Also, many security answer checkers don't do exact matching (since cases, whitespaces, spellings are hard to keep exactly identical), you may want to consider similarity tests. – Jedi Jul 11 '16 at 19:31

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.