Re: [Pharo-users] Why do I not see the transactions when opening a customer

[Roelof Wobben]

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