I think some people are taking this a bit too seriously. This particular example cannot be taken seriously as an approximation of a real bank, and the "credentials" need not be anything other than a simple clear-text string. There is, for example, *NO* interface of any kind (UI or API) anywhere in the challenge, and *NO* test cases or examples from which test cases could be derived. It is at best an exercise in not mucking up *too* badly.
Given that, it's not *that* hard to keep secrets, or it wouldn't be if Pharo didn't have #instVarAt: (:-). So the model code I've attached isn't in Pharo (:-). On Tue, 20 Aug 2019 at 02:19, Roelof Wobben <r.wob...@home.nl> wrote: > Thanks all for the answers. > > As I see it , it impossible to store the password in the bankaccount > object and make safe code to use it, > So some one give me a stupid assignment. > > Roelof > > > > Op 19-8-2019 om 11:38 schreef Diego Lont: > > 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> 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 > > > > >
challenge.st
Description: Binary data
