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 >