On Wednesday, 30 September 2015 at 17:59:41 UTC, H. S. Teoh wrote:
On Wed, Sep 30, 2015 at 04:14:59PM +0000, John Colvin via
Digitalmars-d wrote:
On Wednesday, 30 September 2015 at 14:53:31 UTC, H. S. Teoh
wrote:
>On Wed, Sep 30, 2015 at 08:30:47AM +0200, Jacob Carlborg via
>Digitalmars-d wrote:
>>On 2015-09-29 23:32, Andrej Mitrovic via Digitalmars-d wrote:
>>
>>>If you have plaintext passwords stored anywhere you are
>>>>already
>>screwed. ;)
>>
>>The password always starts out in plaintext, or do you hash
>>it in the front end, as the users types? Since the back end
>>shouldn't trust the front end, it needs to hash it again.
>[...]
>
>The right way to do it is for the server to send a random
>challenge which the front end (presumably running on the
>user's machine) encrypts with the password, sending the
>ciphertext back to the server. The plaintext password is
>never sent over wire, yet the only way the client can provide
>the correct response is if it knows the password to begin
>with.
>
>
>T
right. Nonetheless, sometimes code does have to work with
sensitive data and you don't want it to leak outside the
program in unexpected ways.
Certainly. But I have a hard time imagining a scenario where
I'd use
assert() on sensitive data. After all, assert() should be used
to
verify program *logic*, not the data that the program is
processing.
That's clearly in the realm of enforce() or just plain ole
if(), IMO.
T
Checks involving sensitive data after processing can definitely
be a check of program logic.
Sensitive data enters program
Sensitive data is checked using enforce
Sensitive data is passed to another function, but something goes
wrong (not enough checking before, wrong function called, HDD
dies, someone trips over a network cable), an assert is
triggered, the sensitive data spills to stderr.
A perfectly correct program in perfect circumstances will never
assert, but real programs in real situations will.
At the very least there should be a compiler switch to turn
assert-printing on/off
