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.wob...@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.wob...@home.nl
>>> <mailto:r.wob...@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.
>>>>
>>>
>>
>
