![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlbibJBUChyfsto293eJ0KfDfujin0wEXRqk4jxYiQm3mmmLIOCsl-gA1z3vPAt5NYOjz4yXfQYjkej0__K79roemw_e-_zueQWjWQGx_T6LwqwcyxOtYf3zuJ_J67YRe-wa6VjvyC9vC2/s320/184832.jpg)
But "security" is far from being an absolute. It is a battleground, and whilst some part of that is the general battle for privacy and the stupidity of UK law, the main battles we face fall in to two areas...
1. The bad guys
2. The users
New hashing algorithm
The battle with the bad guys is hard and never ending. Every step you take is a mitigating factor. We have a dedicated ops team and part of their remit is security so they are constantly finding things we should improve to be best practice, or more often beyond best practice, if we can.
Some time ago we instigated a password hashing improvement programme. At the time, the password hash competition was not complete so we went for a heavily salted SHA256 hash. However, the main change at the time was not choice of hash but choice of a system of automatic upgrade. All of the systems we use, where possible, not only use the latest preferred hash but update the hash we have when someone next successfully logs in.
This meant that at the time our accounts and control pages and several internal systems moved to that SHA256 hash very quickly. However, we know that SHA256 was not the best approach as it is a cryptographic hash and not a password hash. There are different types of hash that have different objectives, and a password hash is designed to be time and memory consuming where as a cryptographic hash is designed to be quick but impossible (for some values of impossible) to reverse.
So, having put this all in place some time ago, we recently moved the the competition winner, Argon2. This is a specifically designed password hash, so any successful login will move your hash to this.
Why is this important? Well, it relates to the risk that our database is ever compromised. Obviously we work hard to avoid that, but if it happens then the hashes will not easily be crackable to find passwords. That is the plan. Not all systems allow passwords to be held as a hash, but our various web site logons do.
But tackling the bad guys is not all technology - it is also the social engineering. The call we get at 10 past 5 from someone that is as nice as pie and visiting his parents house for his fathers funeral and does not have the details and just needs this minor change done over the phone. The bad guys are good at this shit, and we have to be vigilant but somehow also allow for the customer that in genuinely in that situation!
But that leads me on to the other battle - that with the users (aka customers).
Bear in mind some ISPs store such passwords in plain text and show to support staff!
Battling customers?
OK that sounds unfair, we should never be battling our customers, but the real battle is human behaviour. People will re-use passwords or use dumb passwords. This is why our password setting system is hard to not accept the pre-set random one we offer. We don't quite make it impossible to pick your own password, because we know of people that do run password apps that provide individual and very secure passwords to use on our system. Sadly, ultimately, we cannot tell such people from those that want to re-use a password or set to "PA55W0RD".
But even then the battle is more subtle - people will store passwords in their browser and then get hacked and passwords collected. People are inherently lazy, and we all know it. We are all the same.
So, our latest initiative is allowing two factor authentication on our accounts system web login. This is an extra step that is not possible (in theory) to store in the browser - a code that changes every 30 seconds from an app or device you have, usually a mobile phone app.
But as part of that we need to also allow people to have trusted browsers that stay logged in, or trusted browsers that do not ask for the code (usually). If we ask for the code every time people will turn off the feature. Remember, people are lazy. Security is always a compromise with convenience.
So we ended up allowing a paranoia setting. Customers can, if they wish, set so the code is needed every time, and even staff will not talk about the account unless you can quote the code over the phone (or irc, or web chat or whatever). But people can set less severe modes where the code is needed on login only if not your usual machine or a recent bad password entry.
We have decided that if you have set up 2FA then we do insist on the code on all orders, even if over the phone. But ordering is rare enough that people can cope with that, we think. The whole 2FA remains optional.
We think we have the right balance of convenience and security now on the accounts web site. Next step is our to our "control" pages. But behind the scenes we are working on more more systems to improve security all of the time.
Thanks for implementing this. I recently changed jobs to a position that makes me highly visible in an area that tends to attract attempts to compromise accounts, so I've been going around adding whatever layers of security I can to my various accounts.
ReplyDeleteMy account with A&A isn't as critical as, say, my DNS registrar, since the worst they can do is cut my fiber line off (right?), but it's still good to be able to protect it better.
How will you handle account recovery? I confess I once wiped my phone before migrating all the OTP keys to the new one.
We are working on the policy on that but anyone set to most paranoid mode is likely to need a letter and/or copy of driving licence or something.
DeletePerfect! Often recovery processes are a lot less secure than the usual authentication method; many insist on sending me a text. Which seems great until you realise how easy it is to social engineer a phone company into transferring your number.
DeleteI called mine (EE) up and asked them to put whatever restrictions they could on my account, but the best they could do was a password and a note to only accept changes if given the password. I'm still not confident they couldn't be social engineered into changing stuff anyway.
re - since the worst they can do is cut my fiber line off (right?)
DeleteIs the bigger risk here not someone getting your phone number and postcode and porting you to a new provider, which has the same effect (I think there maybe a setting to reject these, not sure no longer an A&A customer)
Most folks using OTP pre-generate a list of OTP backup keys that the client can pop in a safe etc. Reason being when I inevitably smash my phone most validator apps do not store the key in the backup.
DeleteWhat I'd like to see (not particularly for A&A, but in general and especially for banking) is more granular account controls so that I could have a read-only login to check things but a separate password required to authorise changes.
ReplyDeleteI'd love to have a banking app that regularly checks my account balance for instance but I'm not trusting any automated process with permissions to transfer money.
Just out of interest, would AA be able to start using EV certificates on their various websites? I'm aware that there are a lot of bureaucratic restrictions around the issuing of them. (I'm a big fan of the clarity of them though, as it stops people being taken in by websites with SSL certificates such as https://barclays-bank-security.com, a domain name owned by me. - Just joking.)
ReplyDeleteEV certificates do cost more, although I'm sure AA could afford it.
DeleteWish they'd merge OV and EV since the validation requirements are similar.
After a series of reasonably sophisticated attempts to get access to my (company) bank account, in the end I simply revoked all my security questions with them and did not provide any more.
ReplyDeleteThe result is that their CS staff can't talk to anyone about the account; I just to have to talk to my commercial banker, who knows we well enough not to be fooled, if I want anything.
It's ever so civilised...
Barclays told me to not use real answers to the security questions, they seemed to think things like mother maiden name etc were easy to acquire, from places like Facebook and birth certificates etc. Whereas Santander doesn't ask any questions like that.
DeleteOut of interest, who's implementation of the google 2fa protocol are you using, or did you write your own from scratch?
DeleteIm pleased to see some security improvements - Your doing better than eBay/Paypal as when PayPal added 2fa they messed up the eBay integration that so convienent.
Err, written from the RFC, as usual, obviously :-)
Deletedoh, should have guessed that :)
DeleteA&A do, of course, store a lot of plaintext passwords: line passwords, telephony passwords, etc.
ReplyDeleteIn the case of older installations, the line password and the Clueless password were set to the same value when the account was created (I'm assuming this no longer happens). This would mean that however wonderful the hashing of the Clueless password was, the same systems also store the same password in plaintext anyway.
This is a situation you should detect automatically and, if you can stomach the support costs, advise people to correct.
Indeed, and something we have discussed. Obviously a lot of passwords have to be available in plain text for RADIUS and SIP but the control page login and line passwords are no longer set the same (for some time now).
Delete> people will store passwords in their browser and then get hacked and passwords collected.
ReplyDeleteDoes this apply to password managers as well, or just browsers? Does a good master password mitigate this?