Password Security | AccountingWEB

Password Security

Last year we had a childishly simple example of how not to deal with passwords when 'Sage Live' was made available in beta

However, there are more sophisticated issues with handling passwords that need to be addressed. Unfortunately the problem with asking questions about password security is that answering the question alone could potentially compromise the situation

Nevertheless the following would seem to be a few minimum guidelines that should be adhered to by all system providers

- passwords should never be stored

- only the salted hash of the password should ever stored

Whilst probably unrealistic it would be comforting for all providers of Cloud systems to confirm that they have handled passwords in the correct manner.

Furthermore, one would expect this issue to be addressed by the various standards bodies (i.e. Code of Practice” by Cloud Industry Forum), although having read the document there does not seem to be any mention of this issue.

This is exactly one of the issues that one would expect a Code of Practice to address

challisc's picture

Important points

challisc | | Permalink

Thanks @JC for raising some important points, which cover best practice and the new CIF Code of Practice.

On best practice, I personally feel userid and password is insufficient for important apps, no matter how the password is stored. Banks use at least one extra level, be it a PIN number, a memorable word, and/or a physical device. An appropriate approach can be adopted depending on the consequences of unauthorised access, which could just be an answer to a factual question such as place of birth. It may be appropriate to offer this as an option, so user organisations who are happy with just userid and password can use the app that way.

As to the CIF Code of Practice, I've mentioned I've recently joined the Governance Board that will be looking at changes to the Code. It's worth realising that as solutions to issues develop, it's not appropriate to be prescriptive in the Code, so the Code provides headings under which a provider can explain their approach. Some of the headings have sub-headings, and "user access controls" and "storage of passwords" could usefully be added to the security section  A.2.7.  If there are other suggestions for changes to the Code, I'd be interested to hear so they can be put forward.


Disagree ...

JC | | Permalink

@challisc - a couple of points

Storage is crucial!

  • how passwords (or additional keys - PIN number, a memorable word etc..) are stored is critical to overall system security because if someone gets at the underlying data in the database, you need to prevent them from using anything they find by making it worthless
  • using any number of additional keys (PIN number, a memorable word etc..) is totally irrelevant as a security measure unless they are stored correctly

Almost any hashed password (hashes are one-way operations) can be cracked in a relatively short time (hours rather than weeks) by using things such as 'Rainbow Tables'. This is the reason for adding a 'salt' to the hashed password because it prevents a 'Rainbow' attack; without knowing the 'salt' any resulting extracted password is meanigless

In this instance the comment '.. it's not appropriate to be prescriptive in the Code ..' cannot hold good because this is recommended best practice and as such compromising data security should not really be optional

challisc's picture

Adding not disagreeing

challisc | | Permalink

@JC,  I wasn't disagreeing that storage of passwords wasn't important, hence suggesting it should be a heading in the CIF Code.  If there is only one practical way of secure storage, I'd expect to see a similar statement from each provider, even under the existing broad "security" title.

However in other areas there are a number of valid approaches, with new ones appearing. So it was decided that it is not appropriate for the Code to be prescriptive in any one area, which seems sensible. The new Code is a first step. This and associated best practice will develop.

david_terrar's picture

Response from one of the vendors

david_terrar | | Permalink

Hi JC,
I just wanted to respond on behalf of Twinfield on how they handle passwords.  All data and requests that are passed to the system are https encrypted.  Passwords are hashed and stored in a special area of the production database that is not available to any support staff, consultants or development staff.  Only 4 senior employees in the company have clearance to access that part of the database.  So no-one inside the Twinfield team can know the password.  There is a mechanism to generate a new password and create a new one if the old one is forgotten.  Lastly, there is an extra level of sign-on security that is available if required - as part of the sign on process a random code is generated and texted to the user's mobile phone so that they must enter that code within sign -on as an extra step.  In terms of external hacking - the Twinfield system is tested on a daily basis by the McAfee SECURE service and the pass/fail result is posted on the login screen. 

I think it would be a good idea to add this topic to the CIF Code of Practice.  I'm on the governance board too, so I'll be lobbying for this addition as well .

David Terrar and

Add comment
Log in or register to post comments