3 deleted 1 character in body
source | link

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 FOOSBOYSSCHOOLFOOBOYSSCHOOL). 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.

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 FOOSBOYSSCHOOL). 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.

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.

2 added 297 characters in body
source | link

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 FOOSBOYSSCHOOL). 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.

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 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.

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 FOOSBOYSSCHOOL). 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.

1
source | link

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 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.