- Pharo-users - lists.pharo.org

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

by Ben Coman

On Mon, 19 Aug 2019 at 22:19, Roelof Wobben <r.wobben(a)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. > That would seem to depend on the purpose of the assignment. a. To produce production ready code that managed someone's real life money, b. Provide a vehicle to reason about typical implementation issues, in which case did you learn anything from the exercise? cheers -ben

Aug. 19, 2019

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

by Roelof Wobben

Aug. 19, 2019

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

by 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.jones(a)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.lont(a)delware.nl <mailto:diego.lont@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 >

Aug. 19, 2019

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

by Jupiter Jones

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.lont(a)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

Aug. 19, 2019

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

by Diego Lont

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 > On 18 Aug 2019, at 18:23, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Thanks, > > I implement almost everything now. > > But I fail to see how to make for password a private variable without getters and setters > and still have different password for every bankaccount and can test against it. > > So please help. > > Roelof > > > > Op 17-8-2019 om 12:48 schreef Roelof Wobben: >> Op 17-8-2019 om 12:33 schreef Richard O'Keefe: >>> Good-oh. >>> Looking at Bankaccounts >>> - the name should be singular, not plural >>> - Smalltalk uses baStudlyCaps >>> > Call it BankAccount. >>> >>> - 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). >>> >> >> Thanks all changed. >> >>> - #addToBankAccount: is an unhelpful name; we >>> know it's adding to a BankAccount because that >>> is where it is. But what is it adding? >>> (Hint: an account might have more than one >>> customer in the real world, so we might need >>> to distinguish between #addCustomer: and) >>> > #addTransaction: , which would be a better name. >>> >> >> the method adds a bankaccount to the bankAccounts collection so maybe AddBankAccountToBankAccountsOfCustomer ? >> >>> - There is a missing method. When you ask a bank >>> account to report a secret, *it* should check >>> the password. >>> > add >>> queryBalance: pwd >>> ^password = pwd >>> ifTrue: [transactions detectSum: [:each | each amount]] >>> ifFalse: [self error: 'wrong password'] >>> >> >> I know its missing. That is the part I still have to figure out.How can I make a collection of all transactions split by account and then the total of it. >> >> >>> Transactions >>> - This too should be singular, not plural. >>> > Rename it to Transaction. >>> >>> - You know it is unfinished. >>> >> >> >> Changed the name and what is missing here then. >> >> >>> Customer >>> - You know it is unfinished. >>> >> >> What is then missing here. >> >>> - Smalltalk uses baStudlyCaps style. The instance >>> variable 'bankaccounts' is two words run together. >>> > Change it to 'bankAccounts'. >>> >>> - The very first method has two style issues and a major flaw. >>> AddBankAccountToCustomer: bankaccount [ >>> bankaccounts add: bankaccounts >>> ] >>> - Style flaw one: method names are expected to begin >>> with a lower case letter, not a capital. (That's C#.) >>> - Style flaw two; we *knew* it's adding to a customer, >>> because that's where it is. >>> > Rename to #addBankAccount: >>> >>> - The major flaw is that the argument 'bankaccount' is >>> ignored, while the 'bankaccounts' collection is added >>> TO ITSELF. This is one of the rare occasions when a >>> type checker would have caught a mistake. >>> > Revise to >>> addBankAccount:aBankAccount [ >>> bankAccounts addLast: aBankAccount. >>> ] >>> >>> - You have a setter, #bankaccounts:. WHY? This should be >>> a completely private variable, initialised when the >>> Customer object is created, and never reassigned thereafter. >>> > Delete that setter. >>> >>> >> Done and Done. >> >> >>> Customer >> AddBankAccountToCustomer: bankaccount [ >>> bankaccounts add: bankaccounts. >>> >>> ] >>> >>> On Sat, 17 Aug 2019 at 21:59, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: >>> Sorry, then a pointed to a wrong repo >>> this is the repo with smalltalk code : >>> >>> https://github.com/rwobben/banking <https://github.com/rwobben/banking> >>> >>> Roelof >>> >>> >>> >>> Op 17-8-2019 om 11:25 schreef Richard O'Keefe: >>>> https://github.com/rwobben/bankaccount <https://github.com/rwobben/bankaccount> >>>> points to a repository with C# code, so I cannot comment on the Smalltalk. >>>> There is, however, a striking thing about the C# code, qua C#, that is >>>> worth mentioning. >>>> >>>> It is not encapsulated. >>>> >>>> Let's start with the most obvious one. >>>> A bank account has a password, and you are >>>> supposed to provide the right password in order >>>> to get information from it. >>>> >>>> Your interface *reveals* the password, so >>>> malicious code can do >>>> var pass = theBankAccount.password; >>>> and then provide the password back. What's >>>> needed is something like >>>> >>>> var balance = theBankAccount.queryBalance(pass); >>>> >>>> where passwords go *in* to theBankAccount but never ever >>>> ever come *out*. >>>> >>>> Another thing is that a BankAccount belongs to a specific >>>> Customer. There's a good way and a bad way to manage this. >>>> The bad way is for the caller to create a new account that >>>> belongs to nobody, and then *tell* the Customer "here is a >>>> new account". With this interface, you could tell any >>>> number of Customers that they own the account. That's >>>> possible in the real world, but in the challenge, it isn't. >>>> The good way is to *ask* the Customer "please create a new >>>> account and tell me what it is", and have no way to force >>>> a Customer to accept an account willy nilly. That way a >>>> Customer can be certain that the accounts it is holding >>>> belong to it and it alone. >>>> >>>> Or it could be were it not for a major encapsulation issue. >>>> The idea of encapsulation is that >>>> EVERY CHANGE TO AN OBJECT'S STATE MUST BE MADE BY THAT OBJECT >>>> including the start of owned containers. >>>> >>>> In Java, for example, you might have >>>> public class Customer { >>>> private final ArrayList<Account> accounts = new ArrayList<Account>(); >>>> ... >>>> public List<Account> getAccounts() { >>>> return Collections.unmodifiableList(accounts); >>>> } >>>> ... >>>> public Account newAccount(...details...) { >>>> final Account a = new Account(...details...'); >>>> accounts.add(a); >>>> return a; >>>> } >>>> ... >>>> } >>>> If you are going to provide access to a collection, >>>> (1) make the collection immutable in the first place, or >>>> (2) return an immutable view of it, or >>>> (3) best of all, DON'T provide access to the collection >>>> but provide queries that extract just the information you >>>> want to make available. >>>> >>>> This has nothing to do with Java or Smalltalk or C# as such; >>>> encapsulation is object-oriented-programming 102. >>>> >>>> For what it's worth, I used to be a University lecturer, and >>>> it was MUCH harder for students to grasp encapsulation than >>>> to grasp recursion. I have no idea why. Just pretend that you >>>> are a nice little object surrounded by malevolent pranksters >>>> who can force you to do anything in your interface, and make >>>> sure they cannot harm you. >>>> >>>> Oh, when I asked about the source of the challenge, what I was >>>> getting at was "is this your paraphrase of the challenge, in >>>> which case please tell us to find the original, or is this >>>> the actual unmodified original text, in which case --ing h---, >>>> you have my profound sympathy." >>>> >>>> This looks like a garbled version of an exercise that I did >>>> a little over 10 years ago, which I found in a Java-based book >>>> whose details I unfortunately forgot to record. Right down to >>>> the names of the classes! That is why I am pretty sure that >>>> there is a description of the problem somewhere that makes sense. >>>> >>> >> >

Aug. 19, 2019

Re: [Pharo-users] Garage

by Jeff Gray

Thanks Sven. Lol - that's a brave new world for me. I have just been a lazy consumer to date! I will attempt to dip a toe into the community proper.... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 18, 2019

Re: [Pharo-users] Pharo-users Digest, Vol 76, Issue 36

by ian

Thanks for your response. Yes, type in the select block. Thanks for letting me know I am on the right track... On Sun, Aug 18, 2019 at 12:00:06PM -0400, pharo-users-request(a)lists.pharo.org wrote: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.pharo.org > > You can reach the person managing the list at > pharo-users-owner(a)lists.pharo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > > Today's Topics: > > 1. Re: As a SmallTalk youngster: A few questions... (Jupiter Jones) > 2. Re: As a SmallTalk youngster: A few questions... (Jupiter Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Aug 2019 09:09:39 +1000 > From: Jupiter Jones <jupiter.jones(a)mail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] As a SmallTalk youngster: A few > questions... > Message-ID: <A74A4769-94D9-4B10-8C74-A8F801806E9D(a)mail.com> > Content-Type: text/plain; charset="utf-8" > > > The difficulty I am having is that when I want to query the UserManager db with something like: > > > > --- > > RcIdentityBag(users) select: [ :each | each name := 'somename' ] > > ? > > Not sure if it?s just a typo, but it appears you?re trying to use assignment ( := ) rather than comparison ( = ) so shouldn?t this be: > > select: [ :each | each name = 'somename' ] > > > It seems that currently the only I know how to do this is to create a select: method in UserManager simply to pass the desired search string into the UserManager class such that I can use the Collection Classes api to do the actual work, as per: > > > > --- Pardon the not so smalltalky code --- > > UserManager>>select: aString > > | resultSet | > > resultSet := users select: [ :each | each name := aString ]. > > ^resultSet > > --- > > > > I believe I read somewhere that in order to avoid this clunkiness that I could refer to the users collection in UserManager via a symbol and access the api of the identitySet directly. Something like: > > > > --- > > UserManager class>>current > > > > > > UserGlobals at: #FOO put users. > > ... > > --- > > > > But when I do this I am unable to do something like: > > > > --- > > #FOO add: user > > --- > > This isn?t really necessary - it?s totally up to your application design. The singleton will work fine. > > > Finally Questions: > > > > 1. Am I totally off the mark with the use of smalltalk symbols? > > 2. Must I create the API in the managing class to perform the specific functions I need from the collection API with respect to querying the collection? > > 3. Is there a smalltalk way of doing this properly that I missed (reading all the docs I can find in random order based of info I need - probably missing the finer points)? > > > > Any nudge in the correct direction would be greatly appreciated. > > It all looks good, apart from the select block. > > Cheers > > >

Aug. 18, 2019

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

by Roelof Wobben

Aug. 18, 2019

Re: [Pharo-users] As a SmallTalk youngster: A few questions...

by Jupiter Jones

Also if you add #FOO to UserGlobals you should be able to reference it like: FOO add: user ie. without the symbol hash (#) > On 17 Aug 2019, at 11:28 pm, ian <ian(a)icjohnson.com> wrote: > > --- > #FOO add: user > ---

Aug. 17, 2019

Re: [Pharo-users] As a SmallTalk youngster: A few questions...

by Jupiter Jones

> The difficulty I am having is that when I want to query the UserManager db with something like: > > --- > RcIdentityBag(users) select: [ :each | each name := 'somename' ] > â Not sure if itâs just a typo, but it appears youâre trying to use assignment ( := ) rather than comparison ( = ) so shouldnât this be: select: [ :each | each name = 'somename' ] > It seems that currently the only I know how to do this is to create a select: method in UserManager simply to pass the desired search string into the UserManager class such that I can use the Collection Classes api to do the actual work, as per: > > --- Pardon the not so smalltalky code --- > UserManager>>select: aString > | resultSet | > resultSet := users select: [ :each | each name := aString ]. > ^resultSet > --- > > I believe I read somewhere that in order to avoid this clunkiness that I could refer to the users collection in UserManager via a symbol and access the api of the identitySet directly. Something like: > > --- > UserManager class>>current > > > UserGlobals at: #FOO put users. > ... > --- > > But when I do this I am unable to do something like: > > --- > #FOO add: user > --- This isnât really necessary - itâs totally up to your application design. The singleton will work fine. > Finally Questions: > > 1. Am I totally off the mark with the use of smalltalk symbols? > 2. Must I create the API in the managing class to perform the specific functions I need from the collection API with respect to querying the collection? > 3. Is there a smalltalk way of doing this properly that I missed (reading all the docs I can find in random order based of info I need - probably missing the finer points)? > > Any nudge in the correct direction would be greatly appreciated. It all looks good, apart from the select block. Cheers

Aug. 17, 2019