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