Hi Jupiter.
This is always a hard problem, as you state: you want a customer to change
their own password, and also want a customer to be allowed to set a password
that he has lost. You could of course make your server code more resilient, and
demand there is security information provided when changing a password.
I.E.
newPassword: aString authentication: anAuthenticationInformation
“ and here you need to verify the authentication information being:
1. user / password of the user that has the account
2. user / password of an administration
3. reset information sent to the user
“
… details can very, but as said: there will always be a back door.
So if it is really important, one should implement strong authentication.
Strong authentication is based on the fact, that a user not only knows
something, but also has something. That is why banks always use things such as
a “rabo scanner” that you need to insert your bank pass (something you have),
type your pin (something you know) and input a picture / code and the result is
a new code that you enter.
> On 19 Aug 2019, at 10:01, Jupiter Jones <jupiter.jo...@mail.com> wrote:
>
> Hi Deigo,
>
> Apologies Roelof for jumping in to your thread. :)
>
> This solves the issue of storing passwords, however, Richard made the case
> for malevolent or broken code…
>
>>>>> - you not only provide a getter for the
>>>>> password, but a setter! This means that
>>>>> malevolent/broken code can do
>>>>> aBankAccount password: 'PWNED!'.
>>>>> and then supply the new password 'PWNED!'
>>>>> whenever a password is needed.
>>>>> > The password must be supplied when a
>>>>> BankAccount is changed and it should not
>>>>> be settable afterwards (except perhaps with
>>>>> a master key).
>
> To scale there is likely the need to allow customers to change their own
> password without call centre or administrator intervention.
>
> Do you know of any implementations of user/password stores that are resilient
> to malevolent or broken code?
>
> Cheers,
>
> J
>
>> On 19 Aug 2019, at 5:40 pm, Diego Lont <diego.l...@delware.nl
>> <mailto:diego.l...@delware.nl>> wrote:
>>
>> The best way to implement a password security is to never store the
>> password, but only a hashed password. This way, you never can have a
>> security leak for your passwords: because you don’t have them. And for
>> hashing you use a standard modern hashing algorithm, so it cannot be easily
>> rolled back. What I often use is that I make the username readonly, and make
>> the hash depend on the username (i.e. use the username as seed)
>>
>> So you implement
>> password: aString
>> self hashedPassword: (self hash: aString)
>>
>> verifyPassword: aString
>> ^(self hash: aString) = self hashedPassword
>>
>> Regards,
>> Diego
>
