Has HL been hacked? New passwords required.

TrustyOven

AnotherJoe wrote: »

Only to someone wearing a tin foil hat.

I know no one that wears one.

Is your reply a form of ad hominem?

"argumentum ad hominem, is a fallacious argumentative strategy whereby genuine discussion of the topic at hand is avoided by instead attacking the character, motive, or other attribute of the person making the argument, or persons associated with the argument, rather than attacking the substance of the argument itself."

TrustyOven

zagfles wrote: »

Surely they just encrypt and store all combinations (salted differently). Eg if the password is 6 chars long and it asks for 3, there are 20 possible combinations so store 20 differently salted & encrypted values.

I don't think it works this way. There are many more than 20 possible combinations.

You get asked for different sets of 3 chars each time you login.

So you could have a password of "password" and then get asked for:

**?**?*?

and

?**?*?**

at two different logins.

So you'd have to provide 's', 'o', 'd' on first login, and 'p', 's', 'o' on the 2nd login.

You'd have to crypt that to get the same hash that is stored in the DB. Hash algorithms would need the full input to generate the same output, so only having the 3 letters each login would be the same as trying to hash "sod" and "pso", and not the full password, and crypt("pso") != crypt("password") so login would fail. They'd have to have a symmetric crypto algorithm I think to be able to decrypt your password, then check the letters in the relevant positions. Or something like that.

greenglide

Surely you just crypt the first character, the second character, the third character etc separately and then test the three characters supplied separately


Doesn't seem complicated.

AnotherJoe

TrustyOven wrote: »

I know no one that wears one.

Is your reply a form of ad hominem?

"argumentum ad hominem, is a fallacious argumentative strategy whereby genuine discussion of the topic at hand is avoided by instead attacking the character, motive, or other attribute of the person making the argument, or persons associated with the argument, rather than attacking the substance of the argument itself."

It's a form of saying that only the sort of person that wears a tinfoil hat is likely to jump to the immediate conclusion that on the sole grounds a company changed their login procedure, therefore that means their customer passwords were exposed / compromised / released. It's such an Flawed argument it's hard not to jump to the conclusion that the person making such a claim is paranoid.

According to the logic of that argument every single company that improves it even just changes its security must have had a password breach. After all why else would they do It? It couldn't be they are being proactive with new systems could it? Or they've come up witha more secure mechanism ? Or they are putting things in place for new technology? Or moving passwords to a crypto box? Nope, their passwords have "obviously" been compromised, let's not even try to think of other reasons, let's just jump to the most ridiculous one. On where's there's been a breach, so they produce a nice glossy leaflet which they post at leisure to their customers and tell them that ina few weeks they'll be asked to change.

Apart from anything else, had such an event happened, the days of companies sweeping this sort of event under the rug are long gone, not to mention the massive penalties that would directly land on those implementing such behaviour, once it was exposed, which again these days, is an absolute certainty that it would be.

jamesd

TrustyOven wrote: »

You'd have to crypt that to get the same hash that is stored in the DB. Hash algorithms would need the full input to generate the same output, so only having the 3 letters each login would be the same as trying to hash "sod" and "pso", and not the full password, and crypt("pso") != crypt("password") so login would fail. They'd have to have a symmetric crypto algorithm I think

If it can be reversed it won't really be as secure as it should be.

But if it's select 3 digits out of 4 you can do things like deciding in advance that you're going to ask for 1st, 3rd, 4th (call it 134), 312, 431, etc for as many permutations as you like. Then say 1234 is the actual number and the account number is 999999 while a "secret" extra part is "Hargreaves Lansdown". Say you want to use SHA-256, which I do for convenience though -512 may be a better choice.

Plug Hargreaves Lansdown999999134 in here and you get 88343f48aba7cf0b102fd6568c8aa6ca56e6b27c1d3737f28e0ea9949c67a85e

Repeat with Hargreaves Lansdown999999312 2813dc33d3c60a3b5c175bd57289b3194ae0b8ab70b6b310db551fa2824976e8

Hargreaves Lansdown999999431 bd6473914b7d5931993b124102871ff35dd6fa4027fb61a13b01e329f5f763f4

Say you save just two bytes from each of those results, you save say 88, 28 and bd. Though you'd actually want to use the binary version of the hash and maybe take a bit or two from each byte.

What you end up with is a very compact way of storing lots of permutations with high confidence that the permutation is known. And even if there's a major data breach because you've stored only part of a salted hash it's somewhat harder to work out what the four digits are.

Only somewhat because four characters constrained to digits is a horribly restricted set of permutations so if the salting is compromised exhaustive checks of all permutations could be tried.

jamesd

greenglide wrote: »

Surely you just crypt the first character, the second character, the third character etc separately and then test the three characters supplied separately.

You could but it'd be a bad idea. Part of a typical design objective would be assuming that the password database is stolen, make it hard to work out what the password was. Do each character individually and you make trying all ten possible values very easy as a tool to discover the actual digits. Assuming that the salting is also compromised, since its job is in part to make such try all permutations approaches harder.

zagfles

TrustyOven wrote: »

I don't think it works this way. There are many more than 20 possible combinations.

That was an example! The number of combinations depends on password length and is n*(n-1)*(n-2)/6 where n is the password length.

You get asked for different sets of 3 chars each time you login.

So you could have a password of "password" and then get asked for:

**?**?*?

and

?**?*?**

at two different logins.

So you'd have to provide 's', 'o', 'd' on first login, and 'p', 's', 'o' on the 2nd login.

Yes. There are 56 combinations. 8*7*6/6. You salt and encrypt all 56 combinations and store all 56 in the DB. So when it asks for **?**?*? you salt & encrypt and check it against the salted & encrypted "sod" in the DB.