Call centre staff selling bank details

On any half decent security system no one has access to the passwords, they're one way encrypted.

Its reasonable to assume that. However, I very much doubt Natwest stores the passwords as one way hash. Reason being when you login to the online banking account you are asked for random digits in your password rather than the full password. I cannot see how they can store passwords as one way hash and then validate my random digits in the password.

Why not? They don't need to store just the single encrypted whole password (or more likely an encrypted version of a message consisting of the username and the whole password). They could just store 8 encrypted messages, one for each password character.

That way, if they ask for 3 characters from the password, they'd need to do three encryptions and comparisons.

Or they could store rather more copies of encrypted versions and do only one encryption and comparison. Suppose they ask for three characters from the password. There are 8x7x6 ways of picking 3 from 8 but each selection can be permuted 6 ways, so they'd only need to have pre-computed

"Ronald Raygun" wrote

Are NatWest's passwords contrained to be exactly 8 characters? [Not 7 or less, or 9 or more?]

That's not the most secure system, is it?

Assuming you are allowed passwords shorter or longer than 8 characters, how do they deal with it then?

No they are not restricted to 8 characters. I do not know why Ronald assumed so. I am still trying to understand his theory.

Why 8 ?

I am lost here. How can they ask for random 3 characters of my password when they should not even know how many characters there are in my password ( assuming its a one way hash). Their software asks me random digits until the length of my password. This surely is not possible if they have encrypted my password as one way ?

I was using 8 only as an example.

I've no idea how they actually do it, I was only addressing webmonkey's point "I cannot see how they can store passwords as one way hash and then validate my random digits in the password.".

If the password is N characters long and they ask for M characters from it, maybe they do just do M encryptions and M comparisons from a pool of N results.

If they use my fanciful scheme involving a single encryption of the set of M characters selected, then the bigger N is, they'll obviously need a bigger pool of pre-computed results. If that pool gets too big, they could just reduce it and limit the range of selections they actually ask for, so they're not spread over the whole possible space.

In any case, passwords much longer than you can count on your fingers don't really lend themselves well to this type of scheme because the punters will lock themselves out too often as they struggle to extract from something like "supercalifragilisticexpialidocious" the 10th, 20th, and 30th characters -- unless, guess what, they write it down. :-(

As I've replied elsewhere, it was just an example. I was too lazy to add "suppose your password is 8 characters long" first. Sorry if that caused confusion.

I was assuming they don't know what any of the characters in the password are, but they do know how many there are.

Why not? They can just remember how long your password is, and then they encrypt each single character separately instead of the whole password all at once.

In practice it'll be a little more sophisticated, for example:

You put in your username "webmonkey" and this gets sent to the bank. The bank doesn't know your password is "spiderpeanut" but it knows that it's 12 characters long. It also knows, for example, the one-way encrypted results for the 12 possible messages "webmonkey01s", "webmonkey02p", etc. So if it asks for the 7th character, and you said 'p', it would encrypt "webmonkey07p" and check it got the right answer. In practice it would use more sophisticated strings than "webmonkey07", I used them just for illustration purposes.

You could easily break a hash that contains a single character that is common, you're talking about less than 40 unique hashes given 26 characters plus a few digits. You wouldn't even need to brute force looking for collisions, just do a few simple comparisons for known hashes for a,b,c... 1,2,3 etc.

By storing each digit as its own hash it basically turns MD5 or SHA into Rot13.

It doesn't matter if the password is stored as plain text in some backend system (provided people can't walk off with the box), however these sort of details should *never* be accessible in their entirety by call centre bods. Most work on a challenge response basis, i.e. 'what is the 1st and 4th character' so the operator should be non the wiser, and the system provides a boolean response (ok, or piss off). Obviously in this case somebody has gained access to backend systems and extracted plain text given the detailed information, even with "just" personal information and account/cc numbers without password details with such depth of information they can reset passwords anyway.

The banks should try and emulate what HSBC has done, the account verification is done by an automated system via touchtone and only after you're authorised are you passed onto a real person, who then greets you with your name and doesn't require any details (and thus isn't required to have access to them, or highly audited access for fallback).

Az.

Indeed, but even if you're comparing with a hash of the entire password you still need the plain text version to fill in the blanks.

The way its stored isn't a problem, somebody can always brute force a hash if its worth the trouble, the fact people have direct access to this info is the killer, they shouldn't have the info fullstop (plaintext or not).

Yeah... and where are these reference strings or secondary hashes stored? See, it becomes a circular argument.

If they were serious they'd need full PKI like issuing customers with challenge-response fobs, or phones/PC's capable of accepting chip 'n pin.

IIRC First Direct insist on password of at least 8 characters, but they only ever ask for characters 1-7 or the last character. So they probably just store chars 1-7 plus the last one.

Yes, but if you ignore characters over 8 (eg use chars 1-7 and the last one as I believe FD do), and you ask for 3 random ones, then for each password you generate 56 hashes for all possible combinations, and you can use the combination position as one of the hash inputs (eg 1,2,3 = position 1, 1,2,4 position 2 etc). Then you get over 2.5 million hash results assuming 36 chars.

It certainly does - low level engineering access is sometimes needed eg for examining disc faults.

How? When you buy from anyone online you normally have to give them all that information.

The First Direct online password has to be "complex" and long - 8 characters sounds about right. The telephone banking password doesn't - mine has a length of 5 characters.

If you phone up and ask for your password to be reset you'll find that info (place of birth, mother's maiden name, favourite colour, blah, blah) is used as fall back verification. A good system should seek further confirmation through the post, but evidently if they're allowing wholesale access to call centre bods there is something lacking.

Given that NatWest have no Indian Call Centres, no.

But that presumes you have access to the pre-computed hashes, which do not generally leave the bank's secure computer.

I'm not with you. If you only ever ask for random characters, and never the whole password, there is never any need to have a hash of the entire password, nor hence to compare anything with it.

I presume they are randomly generated at the time the password is created, and are then stored together with (or preferably separately from, but contemporaneously with) the hashes, and then the plaintext password is discarded.

How so? I'm assuming the hashes are completely safe and cannot leak out of the secure area of the bank's computer. I'm postulating how it should be, not necessarily how it actually is in the case of Natwest and the report which kicked off this thread.

It's possible that even with Natwest the system is safe enough once the ref strings and hashes are in the computer, but there's always a possible weakness if call centre staff are involved in the process whereby the user chooses a password and enters it initially by speaking to a call centre operator. The staff could well be watched to make sure they don't write anything down which they could smuggle out, but some of these guys have phenomenal memories.