On November 2, 2015 5:29:29 AM GMT+01:00, Ralf Quint
wrote:
>The downside of that approach however is that it this opens up the
>possibility to create a matching hash on "inappropriate" passwords (too
>
>short, easy to look up/guess) and hence get access...
And that's why we use cryptographi
On 11/1/2015 7:50 PM, Anthony Walter wrote:
Ideally you shouldn't store passwords at all. You store the hash to
the password. In this way, someone at your business, or someone with
access to your business, or if someone mistakenly installs some
malicious software, your users passwords can never
Ideally you shouldn't store passwords at all. You store the hash to the
password. In this way, someone at your business, or someone with access to
your business, or if someone mistakenly installs some malicious software,
your users passwords can never be retrieved.
When someone logs into your soft
2015-10-30 10:04 GMT+01:00 Marco van de Voort :
> In our previous episode, Klaus Hartnegg said:
> > With password
> > there would have to be a plan B in case users forget a password.
>
> And now you need a plan B for when the user changes email address.
>
Yes, this is where things could go wrong.
In our previous episode, Klaus Hartnegg said:
> With password
> there would have to be a plan B in case users forget a password.
And now you need a plan B for when the user changes email address.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.o
Am 29.10.2015 um 18:08 schrieb Frederic Da Vitoria:
I'd even ask the question: do you really need to store the
passwords? IOW, do you want to be able to send them back to the user? Or
do you only need to check them?
My latest access system does not use passwords at all. The server sends
the us
