Yahoo Insiders Believe Hackers Could Have Stolen Over 1 Billion Accounts (businessinsider.com)

An anonymous reader quotes a report from Business Insider: The actual tally of stolen user accounts from the hack Yahoo experienced could be much larger than 500 million, according to a former Yahoo executive familiar with its security practices. The former Yahoo insider says the architecture of Yahoo's back-end systems is organized in such a way that the type of breach that was reported would have exposed a much larger group of user account information. To be sure, Yahoo has said that the breach affected at least 500 million users. But the former Yahoo exec estimated the number of accounts that could have potentially been stolen could be anywhere between 1 billion and 3 billion. According to this executive, all of Yahoo's products use one main user database, or UDB, to authenticate users. So people who log into products such as Yahoo Mail, Finance, or Sports all enter their usernames and passwords, which then goes to this one central place to ensure they are legitimate, allowing them access. That database is huge, the executive said. At the time of the hack in 2014, inside were credentials for roughly 700 million to 1 billion active users accessing Yahoo products every month, along with many other inactive accounts that hadn't been deleted. In late 2013, Yahoo CEO Marissa Mayer said the company had 800 million monthly active users globally. It currently has more than 1 billion.

Comments

Two years it took to count that high

[Trax3001BBS]

Must of used 1111/

All of it

[Anonymous Coward]

Just say they stole all the accounts. It's also simpler to say: "Everyone who's had a yahoo account (and still cares about it) change your passwords now."

Re:All of it

[gweihir]

Naaa, that may drive customers away. Oh, wait....

Re: All of it

[Anonymous Coward]

All 2 of them?

Re:All of it

[Anonymous Coward]

Or just delete your account at https://edit.yahoo.com/config/delete_user

I dont think I'll miss the Yahoo Groups much either - which was the only reason I created a Yahooo!!!! account.

Re: All of it

[infolation]

I think the whole 'password hack' is a Yahoo ploy to make it sound like they have a billion users.

Re:All of it

[rtb61]

So what is the value of the information appropriated, where they stolen, or was there an executive level, golden parachute scheme, what with M&M her M&Ms on the way out, how much could that data access have been sold for, how many millions.

Unbelievable

[MightyDrunken]

Unbelievable!

700 million to 1 billion active users accessing Yahoo products every month

Oh and the hacking thing.

Re:Unbelievable

[kencurry]

Unbelievable!

700 million to 1 billion active users accessing Yahoo products every month

Oh and the hacking thing.

okay that was funny - mods are asleep at the wheel today.

Re: Biggest government IT failure in history!

[Anonymous Coward]

Companies cheap out whenever possible. That is why the pure Libertarian approach is a joke because companies will break the law, put consumers at risk as much as they can. But then again, the GOP way gives the companies way too much power, and charge the consumers to death(telco industry) with little to no incentive to improve. But the DNC is also just as bad, with onerous regulations/paperwork that literally kills companies.

A mix of these is needed - fewer but powerful regulations, with avenues to competition is needed to give all a chance. But that would never happen, because companies don't want it, because it would work.

Marissa Mayer: Next president?

[Anonymous Coward]

Her technological prowess, transparency and truthfullneess only solidifies her credentials to become the next president of the USA!

Re:Marissa Mayer: Next president?

[Anonymous Coward]

She makes Hillary look like a saint

British billion?

[goombah99]

Is that a british Billion or a USA billion?

Perhaps we can forever rid ourselves of the english language uncertainty over the definition of a billion by renaming the US billion to a "Yahoo".

Re:British billion?

[Anonymous Coward]

Or perhaps Obillion, or Clitillion?

Re:British billion?

[Anonymous Coward]

Is that a british Billion or a USA billion?

The so-called "British Billion" you refer to (i.e. 10^12, or a "long" billion) is all but obsolete in the United Kingdom. Nowadays the "short" version used in the US (10^9) is the accepted standard definition of "billion" here too.

Re:British billion?

[Trax3001BBS]

Is that a british Billion or a USA billion?

Perhaps we can forever rid ourselves of the english language uncertainty over the definition of a billion by renaming the US billion to a "Yahoo".

My best attempt at the 1111 then a slash across the 4 for 5. then again for 10 and on till 500 million.

I'm attempting to access yahoo.com at the moment having a bit of a problem with my password :)

Re:British billion?

[Trax3001BBS]

>

I'm attempting to access yahoo.com at the moment having a bit of a problem with my password :)

Took some time and lots of sms traffic but got in, now I'm just going to delete the account.

Re:British billion?

[plover]

Or perhaps Obillion, or Clitillion?

A "clitillion"? Men would never be able to figure it out.

Re:British billion?

[kencurry]

Those British with their silly walks and special units ...

Re:British billion?

[Anonymous Coward]

Yes, they're still not fully metricified either. Road speeds/limits are in MPH.

I grew up in a 100% metric system, thou my dad and grandfarther would often "think out loud" in various imperial units. I moved to the US in my mid 30's, adapting to the imperial system was no problem, and I actually prefer it now.

I dont see how making everything base 10 is of much use unless you're into science fields where metric become useful.

Re:British billion?

[infolation]

Try buying carpets in the UK. Measured width in yards, length in meters.

Re:British billion?

[Anonymous Coward]

I dont see how making everything base 10 is of much use unless you're into science fields where metric become useful.

Indeed. It's much easier to remember (e.g.) 1760 yards in a mile, or 16 ounces in a pound, or 14 pounds in a stone (think I got that the right way round), or 2000 pounds in a ton- assuming you're using a US "short" ton and not a UK "long" ton (remember to make clear which!)- then calculate with all these different bases together.

It's a whole lot simpler than a regular system whose prefixed names remind you of their relationship to each other and where most calculations consist of little more than moving the decimal point around.

P.S. Can I have some of that crack you're smoking?

Anyone actually use their Yahoo account?

[Anonymous Coward]

Mine was pretty much used a decade ago as an account to sign up for other things that required an email address. Hadn't looked at it in at least 5 years, and deleted it only a few months ago because I thought it probably wasn't good to have this unused account hanging out there.

1 billion active Yahoo accounts? Don't think so.

Re:Anyone actually use their Yahoo account?

[plover]

I use it daily.

Ironically, I've only ever used it for their OAuth service so I could log into other smaller websites, without having to worry about their password storage security. I sure called that one well...

Re:Anyone actually use their Yahoo account?

[Trax3001BBS]

Mine was pretty much used a decade ago as an account to sign up for other things that required an email address. Hadn't looked at it in at least 5 years, and deleted it only a few months ago because I thought it probably wasn't good to have this unused account hanging out there.

1 billion active Yahoo accounts? Don't think so.

No, mine is gone now -well will be in 91 days.

Another feather in Ms. Mayer's cap

[OneHundredAndTen]

Probably one of the worst CEOs ever, down there with Stephen Elop.

Re:Another feather in Ms. Mayer's cap

[gweihir]

Well, Charley Fiorina did pretty badly as well, but I guess these alpha-women must outdo each other. Maybe Meg Whitman can get back into the race again if she manages to kill IBM...

While I know a few quite competent female engineers and scientists, these female CEOs seem to be intent to be much worse than the average male CEO.

More than all of them.

[Anonymous Coward]

Yahoo insiders are optimistic about how many unique accounts use Yahoo.

Re:Fuvking mayer again.

[JustAnotherOldGuy]

Anyone else pissed off that she can make 100's of millions of dollars just by sucking the right billionaires dick ?

I'm not so much pissed as jealous. I'm a straight guy, but I swear, find me someone who'll pay me 100's of millions of dollars for sucking a cock and you can consider it a done deal.

Mayer is clueless

[Anonymous Coward]

I'll bet Google was glad to be rid of Mayer. She obviously fired too many in the security department at Yahoo.

Re:Mayer is clueless

[BarbaraHudson]

They didn't make any bones about it - their first step was to fire a ton of engineers. The "New Yahoo" was supposed to coat along on existing software, acquisitions, and inertia so that it would be more profitable in the short term, making it look more profitable. To bad all software has bug, the acquisitions sucked, and inertia only takes you so far against resistance.

Re:Mayer is clueless

[gweihir]

So you think she planned to kill the company in the long run to make herself look good in the short run? Makes sense to me.

Re:Mayer is clueless

[BarbaraHudson]

No, she planned to make the company look good in the short run to foist it off on someone else and collect an even bigger golden parachute. That is the trend nowadays. Just look at how a company's stock goes up when someone announces a mass lay-off. They know that in the short term, there will be more profits, and if they're lucky, they can unload the stock before it all turns to crap.

Re:Mayer is clueless

[radarskiy]

She was hired by the board of directors to get the shareholders a big payday. She was willing to do it by making the company a going concern in the long term, but the shareholders decided they wanted to cash out quickly.

She added value to the company at a rate of 10 to 20 million USD per day that she's been employed, at a 100:1 return on her compensation. Form the perspective of the people that hired her, that's a big damned success.

Re:Mayer is clueless

[gweihir]

Well, yes. Of course, if many people do that, everything goes to crap in the end, but that seems to be the current trend.

Re:Mayer is clueless

[TroII]

So you think she planned to kill the company in the long run to make herself look good in the short run?

That's precisely what CEOs of public companies are hired to do now. Pump the share price as high as possible as quickly as possible, damn the consequences, and then bail with a golden parachute.

Re:Mayer is clueless

[Anonymous Coward]

Just because you say it, does not make it true, Donald.... "The company reported adjusted earnings per share of 9 cents, down 43% from a year ago. Wall Street analysts had expected the 21-year-old Internet company to report net revenue (excluding traffic acquisition costs) of $840 million, with adjusted earnings of $148 million and EPS of 10 cents. But excluding an accounting change in how Yahoo recognizes revenue under its search agreement with Microsoft, Yahoo’s total revenue would have been $1.055 billion for Q2 2016, a 15% decline from the year prior."

Thank God I don't share passwords between sites

[Anonymous Coward]

After having my gmail account hijacked a few years ago, I began using a password generator/storage program on my desktop and changed passwords to unique passords for everything. It's damn hard to remember passwords such as '67zu2tLqWdfaXe6hV6m5,' but nobody is going to stumble upon it.

sigh...

[Anonymous Coward]

I just saw this at the bottom of the slashdot page:

    by Taboola Sponsored Links .
Techies Are Ditching Skype & Downloading These Alternatives (GetApp)
Use This Trick to Bring Your Old Batteries Back to Life (Never Buy Batteries Again) (EZ Battery)
22 Places You Are Not Allowed To Visit (Viveur)
Imagine Finding A Trap Door In Your New Apartment. You Open ItAnd Find THIS! (ViralNova.com)
George Clooney's Home Is Beyond Stunning (Lonny)

vomity clickbait on this site.

Amazing Incompetence

[Shane_Optima]

So, here is the way to fix this sort of thing using very old, very simple, freely-available tech:

First, all passwords are hashed with salt on the client. If you want to protect a bad (brute force-able) password, you could use secret salt (i.e. a keyfile) hashing layer separately but for maximum portability known salt (like the base domain, "yahoo.com") should be used. This will protect good passwords from being brute-forced without something on the client being compromised, and offers strong protection for password reuse (regardless of whether or not reuse with different services is ill-advised, it will always happen.)

Ideally, this needs to happen via a special API call to the browser itself and not by scripting on the website. The browser is already aware of password fields (this is how it offers to remember logins for you) and thus can in principle alert you whenever an insecure passfield field (or whenever 'no legitimate password field') is present. This would prevent all but the most careless users from having a spoofed website discover their plaintext passwords. I would much prefer that the browser itself handle this hashing but even a javascript implementation of client-side hashing would be a huge improvement over the status quo, primarily because the presence of client-side hashing can be easily detected and audited whilst we have to take them at their word if they claim to be doing this all securely on the backend. (And also because a client-side hash reduces the attack surface such that a database breach or HTTPS attack alone is insufficent--with JS client-side hashing, only a successful website spoof that is undetected by the browser would reveal the plaintext password.)

Next, on the server side, the already client-hashed password is hashed a second time prior to being stored in the database. What does this accomplish? I'm glad you asked! What this means is that a simple read-only database breach does not allow an attacker to log into anyone's account. This is because if they try to use the value stored in the database (post server-hash), it will be hashed a second time prior to being compared to the value in the database, and this second hashing will result in a mismatch. Thus, a successful attack would need to either intercept the pre-server hash value in memory (a much more difficult feat, and one that will only reveal users that log in while the attack is in progress), or they need write permission to the database to overwrite the password, which should sound the alarm in two ways: one by (hopefully) causing database integrity checks to fail, and another by locking users out of their accounts.

The upside of all of this: Good passwords remain safe to reuse on other websites (so long as everyone uses these standards. Websites and apps refusing to use these standards should be aggressively warned against.) Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced. And the CPU load of doing this hashing should be minimal compared with the overhead that HTTPS already imposes.

Now tell me, can anyone explain why this isn't happening yet? This sort of thing would allow us to stop insisting that the most important thing users need to do is memorize a different quality password for every single account they have (impossible for most people.) The elbow grease to do this is minimal and with enough of an outcry, we could easily shame these big name companies into adopting these standards.

(And please, for all you anonymous cowards who want to tell me that hashing with known salt values are useless... go educate yourself on the properties of cryptographically-secure hash algorithms. I don't care about pre-computed rainbow tables. This isn't about protecting weak passwords from brute force attacks. Once offline attacks become possible--which happens whenever a hashed value becomes known, provided the hashing algorithm and salt are both k

Re:Amazing Incompetence

[Shane_Optima]

To clarify: this offers only weak (time-delay) protection for bad passwords. Bad passwords (ones that can be brute forced with offline analysis) would still need to be updated as soon as possible if a database breach happens whilst using this system, but it should still buy some time for people to do this. The only strong protections that can be offered for bad passwords are online delays (which immediately becomes useless once the database is compromised by an attacker) or secondary verification steps (secret keyfiles, biometrics, whatever).

But the protection this scheme offers to users with robust passwords are massive. As it currently stands, users with good passwords are routinely getting screwed by huge companies that really, really should know better.

Re:Amazing Incompetence

[Shane_Optima]

Second clarification: A collision attack on the hashing algorithm does present a problem under this scheme, but it is not a problem that results in the plaintext password from being known. The moment a feasible collision attack with known salt becomes known, the server can safeguard themselves by simply change their hashing algorithm and urges all users to log in as soon as possible, but note two things here:

1. The users do not need to change their password (particularly if it's a strong password, or if there has been no known database breach.) The upgrade can happen transparently and silently and happens entirely server-side, the very next time the user logs in.

2. As implied by #1, a collision vulnerability alone is useless without a database breach also being present.

FYI, I've never worked in IT security in my life, yet I'm pretty sure that half of what CompTIA teaches in Security+ is (at best) snake oil.

Re:Amazing Incompetence

[Shane_Optima]

The client also needs updating if the client's hashing algorithm is vulnerable to collision attacks, but assuming we're talking about a widely-adopted standard that uses a single service (preferably built into the browser itself), this would be a one time update that (assuming automatic security updates are enabled) wouldn't require special action on the part of the user.

Re:Amazing Incompetence

[gweihir]

Please do not listen to this person. He is really, really clueless.

Re:Amazing Incompetence

[Shane_Optima]

You are ignorant of simple cryptographic truths and it is very. very sad (because you are definitely not the only one.)

Go read up on cryptographically secure hashing and explain to me how my system would fail to prevent the attacks I describe.

Re:Amazing Incompetence

[Shane_Optima]

People who've modded this up: Please post AC to explain to me why my system would not work. I look forward to clarifying and/or educating you about how hashing works.

Re:Amazing Incompetence

[Shane_Optima]

Alternatively, here is a message to other mods: an absence of such explanation should be indicative of the fact that these naysayers have, in fact, no idea what they are talking about. And so you really should mod me up as informative, not because I need the karma (I don't), but because we really need to raise awareness that these sorts of security breaches could be mitigated and minimized with a trivial amount of effort.

These extra protections are primarily for those users who have strong passphrases that can't be brute-forced even with heavy offline analysis, but even users with weak passwords will have a little extra protection in that they will have extra time to change their password before the attacker can get around to cracking their plaintext password (which, in the case of hundreds of millions of accounts, could be a great many weeks later.)

Re:Amazing Incompetence

[Stan92057]

well if he is clueless then prove it. saying hes clueless and not saying why is trollish IMO.

Re:Amazing Incompetence

[Shane_Optima]

Nothing? No response at all? How's this then: $1000 to the first one to show how my primary claims here are wrong.

Before attempting this, please be sure to read all of my clarifications (particularly on the benefits this provides to weak vs. strong passphrases). No reward will be given for typos or any incorrect parsing of individual sentences.

Re:Amazing Incompetence

[Shane_Optima]

Yup. I just offered $1000 to the first person to prove me wrong on my main points here (with some caveats.) I mean it, too.

I'm not a security professional or even an IT professional; I just understand things. That unfortunately puts me at a disadvantage in these sorts of conversations. The world doesn't need more false modesty. I may not have used the precisely correct or most common terminology, or laid it out in exacting detail with every single sentence double-checked (because this was a 10 minute slashdot post, not a whitepaper or a doctoral dissertation) but my analyses and arguments here are fundamentally sound.

And compelling.

Re:Amazing Incompetence

[gweihir]

You wish. There are no "cryptographic truths" when you implement anything in practice and, implemented in practice, your "solution" makes things worse. That is one of the reasons why basically nobody competent uses your broken scheme.

But I am not surprised. Amateurs like you think that if you just encrypt right and authenticate right, you are secure. Nothing could be farther from the truth. Crypto is one small building stone in the whole. And no, I am not going to fix your broken idea, I have about 30 years of trying to do that, but crypto-morons like you never listen. They keep insisting on fixing the wrong problem and so will you.

Incidentally, it is called "cryptographic hashing" or a "crypto-hash", the term "cryptographically secure hashing" is not used in the community. Which makes me think you are one of these bright-eyed idiots that have just discovered crypto a while back and have not (yet) discovered that its power is most decidedly limited.

Re:Amazing Incompetence

[gweihir]

No. They are just fed up with any moron that thinks they can do better than the actual experts. And while there are not many actual experts, there is an endless supply of morons. Hence this argument cannot hold water at all.

Re:Amazing Incompetence

[gweihir]

Hahahaha, funny. Offering a pittance (this will not even buy one of my days as an expert) and no assurance you will pay because, surprise!, you are the judge of what qualifies as proof and you already have demonstrated pretty bad judgment.

Re:Amazing Incompetence

[Shane_Optima]

I don't care about terminology quibbles. I've already repeatedly stated elsewhere that I'm not a professional. If you do know anything at all about cryptography, I am assuming that you understood what I mean. Hashing functions can more either more or less secure when it comes to collisions or leaking information about the information being hashed. In my post, I was referring only to the most secure hash functions available.

The fact is that passwords are being routinely being stored in plaintext and this is causing tons of problems for people using and/or reusing STRONG passphrases. Proper hashing should in principle remove these concerns, make it much harder to log into the account of someone who uses a strong passphrase even after a database breach, and make it much, MUCH harder to break into another account elsewhere that uses the same password (but different salt.)

At no point did I argue that my solution was a comprehensive one; I explicitly noted that I was taking HTTPS for granted. I also said that certain supplemental pieces like secret keyfiles would be beneficial, though they require more effort on the part of the user and thus are less likely to be widely implemented.

Furthermore, there are time delay benefits even for users of weaker passphrases, particularly in mass leaks like this where the attacker can't possibly crack hundreds of millions of passwords in a short time frame. This time delay allows more people to change their passphrase in time.

If you disagree then explain yourself. Or you can keep on making an ass of yourself; it's your choice.

Re:Amazing Incompetence

[Shane_Optima]

A thousand dollars if you can back up your bullshit with sound rebuttals. I'm serious.

Typos and misparsing of sentences from my original very quickly written post do not count--I've already given you multiple clarifications of what I'm intending here and what the benefits would and would not include.

Re:Amazing Incompetence

[Shane_Optima]

I'll put it to a slashdot vote. If they vote that you've rebutted the core of my argument (not quibbled over about individual sentences from a hastily written post that was never intended as a doctoral dissertation), you get the money.

Come on, you old-timer fraud. Put up or shut up. You're either too lazy to read what I've said in detail or you know I'm right and you're continuing on out of stubbornness.

Re:Amazing Incompetence

[gweihir]

I just had a second look and realized you do not even seem to have heard about _iterated_ hashing, which is the standard for now > 40 years (UNIX-passwords started it, I think, and at that time they did not even have proper crypto-hashes). And that is already an outdated thing as it is considered not secure enough in an age where graphics-cards get ever more powerful. I am sure you have not heard of things like Argon2 (that fix iterated hashing) either.

So, seriously, how incompetent can you get? Talk about an extreme left-side Dunning-Kruger sample.

And then you want to change all browsers...

Re:Amazing Incompetence

[Anonymous Coward]

Jesus christ. This is well-trod ground: https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism. Some humility would serve you well, regardless of whether you're right or not.

Re:Amazing Incompetence

[Anonymous Coward]

You will not get far in the world with this attitude. It's fixable. Fix it.

Re:Amazing Incompetence

[Shane_Optima]

I never claimed it was novel. It just isn't being used and it should be.

If people want to pay me to search for prior art for every single post I make, I'd be happy to. The point isn't that I'm the first one to think of what is, at root, an extremely obvious idea once one-way hash functions were developed for cryptographic use. The point is that the vast majority of industry leaders are not properly using these functions, even though they would require very little overhead, no changes that the user would notice and yet would offer a TON of mitigation for these types of breaches for users of strong passphrases. There would also be moderate mitigation for users of weaker passphrases--they may have enough time to change their passphrase before the attack can get around to cracking their hash (in this case, out of the hundreds of millions that have been stolen.)

I also require prepayment if you want me to take the time to phrase everything in extremely polite or modest terms. People are doing stupid things and it's fucking up the lives of millions of people. Here's a fairly effective solution, not 100% effective but it's very easy to implement and makes life a lot more difficult for the attacker. Go use it. Refuse to use it, and I will call you a dumbass the next time one of these breaches happen and they one again imply that login credentials were stolen even for users who were not logged while the attack was in progress.

If at that point you want to call me an arrogant jerk for my criticism, feel free. But they'd still be dumbasses for not taking these simple measures.

Re:Amazing Incompetence

[Shane_Optima]

I don't come to slashdot to suck up to people by pretending bad ideas aren't bad. Storing passphrasses as plaintext, as many sites are clearly doing, is an objectively horrible idea that my easy-to-implement solution fixes.

It may not be the optimum solution, but it is easy, cheap and effective for the purposes I've described. People who think that extreme politeness should come before correctness are a major scourge in this world.

Re:Amazing Incompetence

[Shane_Optima]

I proposed a fix for an existing problem. You said my fix was broken.

If you, the alleged professional, want to improve on my fix then I'm sure you could. That does not change the fact that my fix is in fact a fix that is objectively superior to the way these assholes are currently conducting things. And it doesn't change the fact that my fix is not actually broken, merely that it requires fleshing out.

And I never said it didn't. This was obviously a 5000 foot proof of concept thing that I literally bashed out as I was eating a sandwich. If you want me to do the research and write you a fucking dissertation with 100% correct terminology and proper usage of every single crytographic technique, I require prepayment for my time.

Your claim that my fix (for the still-prevalent practice of plaintext password storage) is broken is clearly false, but you still can't admit it.

Re:Amazing Incompetence

[Shane_Optima]

Also, as I stated in one of my early clarification posts, by "cryptographically secure hash" I was referring to the most secure hashing functions available regarding leakage or collisions. If the most secure hashing function is a form of iterated hashing than that's the one I was referring to.

This is like me criticizing someone for using a longhaired Chihuahua as an attack dog, and your response is that I'm a moron and my suggestion is "broken" because that's really a Pomeranian, not a Chihuahua. Congratulations, but that's not what the discussion is about. I've already conceded that I'm probably not using perfect terminology, but my intent is clear. People are doing dumb shit that is severely inconveniencing millions of people. Here is *a* fix. You, the professional, go make my fix better by fleshing out the details or finding an existing concept that does something similar.

Or stand here and argue my ideas are inherently broken, and keep arguing that every idea for reform is broken when it comes out next month that Amazon was storing all of *their* passwords in plaintext in a database, which has just been leaked.

Re:Amazing Incompetence

[gweihir]

Get at the very least 10 year professional practical experience with crypto, then come again and complete your theoretical knowledge, because that is as well lacking. You are so clueless it is painful. Application of cryptography is one of the hardest fields in Computer Science, and amateurs cannot contribute because they lack the basic understanding required. Sure, this sounds arrogant, but there is no helping that because it happens to be true. Would you suggest new ways of doing brain-surgery without being a qualified brain-surgeon? Of course not. But for some reason I still do not understand, when it comes to crypto, every amateur thinks they can tell the professionals how it is done. And that _is_ arrogance on your part.

And no, I am not going to try to fill you in on the things you would understand here if you were an expert. You are not even going to be able to understand what I am talking about.

Re:Amazing Incompetence

[gweihir]

$1000 buys you about 4 hours of my time. I do not take jobs below 5 days. And I do not take "convince a moron or do not get paid" jobs either.

Sure, I can tell that you are pretty smart, but what makes you a moron is that you think you are much smarter than you actually are. And that makes you fail at recognizing the actual difficulty-levels of things. To use crypto right you have to be pretty smart _and_ you need a lot of experience. One decade is on the low side and that is after at least a full CS master with a crypto-specialization.

Re:Amazing Incompetence

[Shane_Optima]

You've yet to give a single concrete criticism of my ideas except that I said "cryptographically secure hash" instead of "iterated hash." You know why I said that? Because I don't KNOW what the most secure hashing method is, the precise details of its operation, or what it is officially named! It's your job to know that shit. You. The alleged professional.

This is just pitiful. A 5 digit ID and an alleged professional and the best you can do is a hand-waving appeal to your alleged professionalism. You can't haven't come up with a single relevant criticism of the substance of my ideas, even after I sincerely offered a $1000 reward for doing so. Here, I'll get you started.... here are some SAMPLE criticisms you might conceivably put forth:

1. Do you think the hashed passwords can be reverse-engineered so quickly as to make the protection irrelevant? (If so, you know clearly something about modern hashing algorithms that the rest of us don't, and I'd be very interested to hear it. Or would you have to kill me if you told me?)

2.Do you think that a secure-enough hashing algorithm would be too computationally expensive, even though I explicitly said we were talking about situations where HTTPS was being used?

3. Do you think that there is some other huge advantage to having passwords stored in plaintext on the server? (I really can't think of any)

4. Do you dispute that Yahoo was storing passwords in plaintext in this case? (I haven't looked at the details here but the article summary clearly implies that this was the case, as all offline users with strong passwords should be unaffected by any database leak if hashing were properly implemented, because their pre-(server) hashed passwords could not be known.)

5. Do you think compliance will be too hard to enforce? I've already conceded this is tricky for the server hash, but I also made clear that was one of the biggest reasons to also use a client-side hash. I explicitly said that this could in principle be audited and pressure put on anyone who refuses to use client-side hashing.

6. Summarize your defense of yahoo's security practices at the time of this breach.

7. Summarize your ideal solution or mitigation for database leaks, preferably one that does not require that the users jump through any hoops (Since I acknowledged that these solutions, while obviously stronger in principle, are harder to convince people to implement or correctly follow.)

8. You might complain that there is prior art or what I'm suggesting is non-optimal. This objection has already been raised and conceded on my part, but that doesn't mean my idea is "broken", merely that they're not completely novel and they could be improved with further tweaks. And I'm not at all surprised about either of those things. I never claimed to be original or definitive. This was a ten minute post inspired by some drunken brainstorming I did two nights ago, and I'm not a crypto professional.

But you don't need to be an attack dog expert to realize that Chihuahuas make shitty attack dogs. "You should buy a bigger dog" is the correct solution, even if I can't tell you the exact breed to buy because I'm not a dog expert. I might even be wrong about it being a Chihuahua. I might be such a ignoramus when it comes to dogs that I call it a Pug. But you know what? That doesn't mean my solution to buy a bigger dog is "broken".

And you're a twat for attacking me instead of the incompetents over at Yahoo. Not because I'm thin-skinned, but because it is a travesty that total incompetents are put in positions of power and allowed to severely inconvenience (sometimes even ruin the lives of) millions of people and as an alleged security professional this should be the only thing you care about here.

Re:Amazing Incompetence

[Shane_Optima]

I don't have to be a car expert to know that you don't want to put your antifreeze-water mixture into the gas tank.

Provided the summary here is accurate (this was a database leak only and yet accounts that were offline had their login credentials compromised, with no comment about the strength of the passphrase mattering), this is a fuckup of the highest order here and yet you apparently haven't offered a word of technical criticism of it.

Thus, I think it's reasonable to conclude that you are a troll, not a professional, and/or you're for some reason ultra-sensitive about the good folks at Yahoo being criticized.

Re:Amazing Incompetence

[Shane_Optima]

Update: Half a dozen posts later and the best he can come up with is continually criticizing me for not having a CS degree and ten years of experience. A undisguised appeal to his alleged authority and insults... that is literally all he has.

Oh yes, there's that and he objected to me saying "cryptographically secure hashing" and in his very next post he disparaged me for not mentioning, by name, "iterated hashing" because according to him, non-iterated hashing is insecure. I'll let you connect the dots on those two brilliant nuggets of criticism.

I never claimed to be an expert, or to be writing a dissertation or a carefully constructed white paper. The only actual criticism he can offer is for not using his preferred jargon, whilst on the topic of the astounding incompetence over at Yahoo he remains mute. And the jackass is still modded +4 Informative.

Re:Amazing Incompetence

[Shane_Optima]

Pretty sure you've given up at this stage, as you obviously don't have the knowledge or the chops to actually engage me in a debate. I was trained in an extremely technical field and I could and still can debate any point with which I was familiar with anyone, layman or not.

I don't have the time to give you a good picture of humanity's true nature but I will tell you this: appeals to authority usually mean almost nothing, and I've never underestmated the ability for people to engage in and promote incompetent and self-destructive practices, even if it's over a very long period of time whilst in highly visible positions. Nobel Prize winners have shown themselves to be crackpots who believe in pseudoscience. Even within their own field, decades of stagnant busywork have completely rotted the minds of many one-time experts. I don't and can't say for sure that this is what has happened to you, but you are exhibiting the symptoms very strongly.

An inability to justify one's reasons for liking or disliking an idea in a succinct way is one of the defining characteristics of the disease. You should consider an early retirement ASAP, or at the very least a long vacation.

Re:Amazing Incompetence

[Anonymous Coward]

This design seems helpful, and I'll consider using it for my own long tail website.

However I wonder if it would be better to go straight to U2F, which makes similar promises: read-only compromise of the database doesn't allow impersonation, and multiple https origins can share the same U2F key without colliding or learning anything about one another.

Re:Amazing Incompetence

[gweihir]

Keep telling that to yourself, eventually you may believe it. Fact of the matter is that it is a complete waste of my time engaging with you. The defects in your design are obvious to anybody with in-depth experience. They are not obvious to you. I cannot fill in your lack of experience.

Re:Amazing Incompetence

[gweihir]

Fascinating. The only thing you are demonstrating here is a very much over-sized ego. And incidentally, you are not the least bit unique. I have seen a lot of broken crypto designs over the years, yours is just one more.

Re:Amazing Incompetence

[Shane_Optima]

You've no idea. This isn't about ego at all; I simply enjoy watching people make asses of themselves. Feel free to call me a sadist, if that makes you feel any better.

And it turns out, I can do your arguing for you! I found another crypto "expert" that I'm IMing at the moment and just like you he threw a hissy fit at first, but after 45 minutes he was forced to concede every single one of my core claims, while still claiming that it would never work in practice because they would never do it, which isn't an argument I find very compelling.

But your problem, I believe, is a psychological aversion to offline attacks. You like shit to stay online where things can be drastically limited and even CAPTCHAs can be used. Fair enough: ok then, if you're paranoid then you're allowed to change your password after a break, even if it was a very strong password. Who said you couldn't? Security is about roadblocks, not absolutes. And you can put a huge roadblock up by applying a good hash to a good password, a roadblock that shouldn't be breakable by any world power today in a reasonable time frame. But, then, I might be slightly more tenacious than most; my FDE password is over 100 characters.

Speaking of good hashes, you also may have an unhealthy mental picture of the purpose and limitations of hashing algorithms. In reality, collisions don't have to be a problem if you don't let them be. At first, the guy I'm talking to wanted to argue like crazy that collisions were always inevitable until I started pointing out some of the mathematical properties of some of these hash algorithms, and also that the size of hash output could be whatever you wished.

You also may believe that pandering to lazy people with weak passwords is of paramount importance. This is a matter of opinion, I suppose. I lost two accounts with a very strong password due to some jackass at eBay apparently storing it plaintext. This is preventable. I've successfully trained most of my family to use quality passphrases. None of them would lose their accounts if this were all properly implemented. Let's save the smart and diligent people and then circle back for the lazy and stupid; that's my motto.

Also, you're against forcing the people running websites to change, because reasons.

Am I getting warm?

You aren't terribly unique, either.

Re:Amazing Incompetence

[Shane_Optima]

The fact that you think this about ego really says it all. You think that I think that this is some brilliant, complex, end-all and be-all solution. I explicitly said it wasn't. It isn't a credit to my intellect, not in the slightest. It's a 'credit' to yahoo's stupidity that they didn't do this. And it's a credit to yours that you've posted like what, perhaps ten pointlessly hand-waving posts of zero content, arguing that my ideas are broken because you have more than ten years of experience, that's why!

I can't even begin to describe how much joy it brings me to hear you spout such idiocy. Please, do it again.

Re:Amazing Incompetence

[Anonymous Coward]

• Javascript Cryptography Considered Harmful (probably the most widely cited article on this topic)
• Cryptographic nonce (specifically the "Hashing" subsection)
• Key derivation function (with attention to the NIST citations)

Without trying to delve too deeply into some of the more frustratingly complex (and full of subtle pitfalls, much like applied cryptography in general) aspects of this topic in a single Slashdot reply, I'll try to offer a basic synopsis of some immediate concerns. When you hash the password on the client, especially (and quite dangerously) if you're using a known and/or easily guessable salt, the hash you transmit to the server simply becomes a markedly weaker authentication token. A few frequently cited (and each interrelated) resulting drawbacks would include known fixed token length, dramatically reduced computational search space, heightened traffic analysis potential, inescapable and severe credential entropy reduction, much more easily executed simple {dictionary, precomputation, preimage} credential recovery attacks, etc.

Once the token arrives at the server, per your scheme it would be rehashed, but with what salt? Server side salt reuse here yields the same concerns, and in fact would only serve to further dramatically worsen the utility of the credential in question. Properly formed salted hashes are not validated via textual equivalence comparison, but rather via feeding the salted hash and the original secret into the hash's validation algorithm. You might find the basic Perl implementation of Crypt::SaltedHash illustrative in this regard.

As I mentioned earlier, this isn't an exhaustive list of of the issues associated with this topic. In the best case, the system you've proposed would add no substantive security margin to weak passwords, and would seriously weaken stronger passwords. If you like, please feel free to email me for further discussion. -PCP

Captcha: certify

Re:Amazing Incompetence

[Anonymous Coward]

Just to be more linguistically clear in terms of validation, you validate the user supplied secret against a properly formed (that's important) stored salted hash stored server-side via a separate algorithmic construct. You never perform a straight bit-wise comparison of any such values (regardless of any intermediary hashing or other transformative operations that may have been performed at any earlier stage). On a tangential note, highly effective cryptographic attacks, remotely and locally executable alike, have been derived from implementation flaws as simple as failing to perform string primitive comparisons and other basic operations in constant time. -PCP

Re:Amazing Incompetence

[Anonymous Coward]

Thanks for posting this. Sometimes we need a short and simple post to mod up.

Re:Amazing Incompetence

[Anonymous Coward]

Look, if you want a proper dissection of your claims, go make a post at security.stackexchange.com, though I think it might be tagged as "too broad" if it's all in a single post.

You're misusing terminology, your proposal is not backwards compatible (Javascriptless clients), and while it all would end up with a passable end result (I cannot quite tell), less effort would be needed from the coder by just doing security properly in the first place. Furthermore, you've shown in previous threads that you're willing to dismiss any arguments against your proposal.

The simplest way to make things secure is by using HTTPS and a store_database(hash($password || $salt)) call in the server code. It's a tenth of the workload that your proposal has, and is just as secure if the hash function is properly chosen.

Re:Amazing Incompetence

[Anonymous Coward]

Oh, and by $salt I mean a user-specific random string, not your odd definition of salt.

Re:Amazing Incompetence

[Anonymous Coward]

Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced.

Please review the following quick demo. It took me less than an hour to produce, including the run time to generate its output using a single CPU core of an old Celeron G540 box (vintage 2011 desktop hardware). You should notice that it generates pseudo-random crappy 8 character lowercase passwords (which still beats what a lot of folks use) and produces salted SHA-256 hashes of them. For the first run, a static salt of "yahoo.com" is used for each salted hash. For the second run, nine randomly selected bytes from the standard ASCII set are used for each salted hash. The end result is 225 people unwittingly sharing the same hash in the first case, and zero duplicate hashes for the second case.

Demo: rand-salt.pl

Please let me know when I may collect my $1,000. My family sure could use the money; I've got kids. That said, I'm also committing to send 25% of the funds ($250) to gweihir as an expression of my appreciation for his contributions to the Slashdot community over the years. You have my word on that. Let's see if you keep your word in turn. Your move.

Re:Amazing Incompetence

[Anonymous Coward]

I guess we'll see if he's ready to back up his promise with a payment. -PCP

Captcha: procures

Re:Amazing Incompetence

[Anonymous Coward]

Storing passphrasses as plaintext, as many sites are clearly doing, is an objectively horrible idea that my easy-to-implement solution fixes.

That's the damn thing. Your idea is not easy to implement. It takes much less effort to do it correctly on the server side. Why do you think people who cannot follow basic security practices would manage to follow your idea?

The downside about the correct server-side way is that you, as the user, cannot know whether these security measures were taken at all. And in fact, I'd argue that with any JS-based solution an average user couldn't either (especially when all these offending sites tend to spew hundreds of KB of javascript to the browser anyway ...)

Re:Amazing Incompetence

[Shane_Optima]

And in fact, I'd argue that with any JS-based solution an average user couldn't either

But security bulletins could be posted. Companies could prevent people from visiting sites that refuse to use client-side hashing. Browsers could warn you with dire-sounding popups. Pressure could be brought to bear. As I've already described, it doesn't replace server-side hashing but if they are dumbasses about it then it at least mitigates some of the damage done by a lack of server-side hashing.

It's only "not easy" in the sense that any change requires work. It's not something that requires much more CPU work than what HTTPS already requires. It's not something that would take more than a couple weeks to set up, test and deploy. Do you disagree?

Re:Amazing Incompetence

[Shane_Optima]

1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.

2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic.

3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)

4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.

You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.

Re:Amazing Incompetence

[Shane_Optima]

C&P:

1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.

2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic. In particular, the hash should be able to handle on par with the maximum password length and the hash output should exceed the size of the input, possibly greatly exceed it.

3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)

4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that a secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.

You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.

Re:Amazing Incompetence

[Shane_Optima]

No payment for fools who don't understand how to use hashes properly. In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.

This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.

Re:Amazing Incompetence

[Shane_Optima]

C&P: No payment for fools who don't understand how to use hashes properly.

In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.

This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.

Re:Amazing Incompetence

[Shane_Optima]

You're misusing terminology

Repeatedly conceded. I'm not a professional cryptographer.

your proposal is not backwards compatible (Javascriptless clients)

That's fine--all sites that work properly without javascript are exempt. OK? That still leaves us with 90%+ of the web, which does require JS. Also, I further specified that I'd prefer to see this as a browser function akin to HTTPS.

less effort would be needed from the coder by just doing security properly in the first place.

Unfortunately, we've seen repeated proof that you people cannot be trusted to do it properly on your end. With client-side hashing, strong pressure can be brought to bear on people who aren't using it, companies can prevent their employees from visiting insecure sites, browsers can generate warnings about insecure password fields, etc. They should still use server-side hashing, but if they lie about it then we at least will have the protections that client-side offers.

Furthermore, you've shown in previous threads that you're willing to dismiss any arguments against your proposal.

Citation needed. I've endeavored to address every single objection raise, although so far they've been fairly boneheaded and impolite objections so you shouldn't expect my responses to be candy-coated.

The simplest way to make things secure is by using HTTPS and a store_database(hash($password || $salt)) call in the server code.

You. assholes. cannot. be. trusted. I'm not idly saying this! I've lost two accounts with a very long, unbruteforceable password apparently due to plaintext database storage being used. I've already had one AC poster, ostensibly a slashdot regular working at a major company, talking at length about how they are using plaintext storage and have refused repeated calls to implement salted hashing.

Re:Amazing Incompetence

[Shane_Optima]

When you hash the password on the client, especially (and quite dangerously) if you're using a known and/or easily guessable salt, the hash you transmit to the server simply becomes a markedly weaker authentication token

Demonstrably untrue and indicative of someone who doesn't understand the first thing about hashing algorithms. I'm not saying you can dump it into a single iteration of your command line version of SHA and automagically get something that works. It has to be intelligently constructed, properly utilize all input, and produce output that significantly exceeds the size of the input. If the password field has a maximum, let the hash output be twice that size. Are you still going to argue that "markedly weakens" it? My gut says that if you used a 1:1 algorithm stage in there somewhere that it wouldn't even need to be that big, but I haven't had time to research this in detail. I'm not an expert; I just am not a moron about these things.

I'm sorry if this is rude but I've been more than patient up until now: You people are fucking clueless. You apparently think that just because you've set up a few HTTPS webservers and you use these shitty command line things that you call "hashes" that somehow makes you an expert on information theory. *I* don't claim to be an expert, but I'm also not wrong.

Once the token arrives at the server, per your scheme it would be rehashed, but with what salt? Server side salt reuse here yields the same concerns,

Server should use random salt; sorry if I didn't make that clear. The static salt is for client side only. Random salt for client is either a secret keyfile (undesirable for usability reasons) or it's transmitted from the server, which is makes it just a pointless redundancy with the server-side hash. You *could* have both sides use random salt, I guess. It wouldn't hurt. I was just trying to keep things simpler than that. Random salt that is broadcast is obviously less desirable than random salt that is kept hidden on the server.

I appreciate the effort you're making but I really would like for us to be on the same page before I make any further effort to research and provide you with a more detailed spec of what I'm thinking of here, if indeed that is truly necessary. Several of you guys are misstating what I'm advocating and also asserting blatant falsehoods about hashes worsening security.

Re:Amazing Incompetence

[Shane_Optima]

Yes, because incompetent jackasses who refuse to provide any explanation whatsoever deserve +5 informative.

I've shot down every objection people have given, and I've convinced someone who has a CS Masters degree and experience with cryptography that my design (which was never asserted to be a comprehensive solution, just an easy and important improvement) is fundamentally sound and desirable.

Re:Amazing Incompetence

[Shane_Optima]

Hey, it looks like all of your friends around here think I'm wrong because they seem to think that "hash" means a single default invocation of whatever CLI version of sha they have lying around, without any regard whatsoever to the size of input and output.

Is that what you thought? Is your brain so ossified that you cannot conceive of the fact that, in the presence of input maximums (which all websites have with the password fields), it is in fact entirely possible to construct a hash algorithm that does not generate collisions?

I'm still having to guess at the source of your idiocy here, since you refuse to explain yourself. I'm breathless with anticipation to find out if I'm right.

Re:Amazing Incompetence

[Shane_Optima]

Upon further consideration: A single random server-provided salt is more desirable for the client-side hash since it does prevent the use of rainbow tables; however, I'm not particularly impressed since it's redundant with the random-salt server hash and the salt can be easily obtained by any attacker. The only significant advantage here is it prevents rainbow tables from be used in the case that client side hashing is present but server doesn't do any hashing... so, if you entirely agree with my philosophy of protecting ourselves from incompetently administered backends, then yes, by all means use different client salt value for each client, a value that the server must provide to anyone who asks.

So, I've identified a reason for doing what some of you are suggesting but for completely different reasons, and you are still very, very wrong about the properties of competently designed hashes.

Challenge-response hashing would be yet another interesting layer to add, but I'm not sure I like it. It requires that the client and server both have access to the same initial value to hash, which I view as inherently undesirable (I want the server to have access only to a hash that used random salt known only to it), but the randomization of client salt *is* interesting. Needs further pondering. I'm distracted at the moment. I'll get back to you.

Re:Amazing Incompetence

[Stan92057]

Well i only seen this if hes following you just ignore or say put up or shut up not much else ya can do. I would have modded him flame bait or troll if i had mod points at the time i didn't so i commented. Too many trolls abuse this site anymore its a damn shame.

Re:Amazing Incompetence

[Shane_Optima]

https://slashdot.org/comments.... *Cannot* be trusted.

Re:Amazing Incompetence

[Shane_Optima]

Or is this a jargon issue? Am I wrong because I didn't say "key derivation function" instead of "hash"? I really don't care. I'm not even going to look it up on wikipedia; I've no desire to learn about the intricacies of your silly little DSL; I don't need to in order to understand that the incompetence of your industry is screwing over millions of people. You know my solution is entirely effective, because it does not decrease security (properly implemented) and unlike server-side stuff is it actually audit-able.

And the fact that you choose to badmouth me and hide behind pseudonymity instead of debating or providing an equivalent system of your own (using all of the correct magical words that you special snowflakes have invented for yourselves) makes you complicit in that incompetence. What incompetence? This incompetence: https://slashdot.org/comments....

Re:Amazing Incompetence

[Anonymous Coward]

No payment for fools who don't understand how to use hashes properly. In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash.

There's nothing bungled about the reference programs I gave you, at least not in terms of their functional correctness, faithful adherence to the SHA2/SHA-256 specification, and your suggested course of action. If you haven't done so already, run both programs and see for yourself. Everything I gave you, including the backing modules for SHA-256 hashing and CSPRNG functionality, is open source software that anyone can review (and an enormous number of people have done so).

You shouldn't have tons of collisions like that.

You will absolutely get collisions like that when your input is insufficiently distinguishable from a large number of other inputs, owing to the use of static/known salt. Furthermore, you will note that there were zero collisions in the output for the program that used a randomized salt for each input.

A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.

At best, that is a naive view of the subject matter at hand. In the mathematical sense, hashing algorithms may be generally described as compression functions which take an input of a specified size range, apply a series of mathematical operations to said input, and produce an output (digest) of a specific fixed size. Input sizes (typically measured in bits or bytes) may be smaller than the output digest size (also typically measured in bits or bytes), in which case a good hashing algorithm should produce, on statistical average, outputs which are evenly spaced in the total search space per the normal distribution. However, input sizes which approach or exceed the output digest size either must (in the case of digest size being exceeded) or are highly likely (in the case of inputs without sufficient bitwise differences) result in collisions at some point. An astute observer might mention that there are subsets of this family of algorithms, having the strict stipulation of input sizes being less than the output digest size, which are referred to as perfect hashing functions. These are actually relatively rarely used for typical cryptographic applications, and for various good reasons.

I encourage you to engage in more personal independent study on all these points. The information you seek is readily available, free of charge. Going forward, while gaining a better understanding of these principles may only cost your time, the fact remains that the example I provided decisively demonstrates your flawed understanding of the subject matter at hand and invalidates key assertions you've made in this whole discussion, and thus you owe me USD $1,000.

In closing, I received your email a few minutes ago; thanks for sending it. I'll reply again there later today with further thoughts and suggestions for avenues of payment on your outstanding debt. -PCP

Re:Amazing Incompetence

[Shane_Optima]

ecisively demonstrates your flawed understanding of the subject matter at hand

Blah blah blah. It merely proves I don't use your jargon, which is something I repeatedly admitted up front. I am fairly positive could design something utilizing SHA with zero collisions, given an aggregate storage space for output from the hashes that was significantly bigger than the maximum password size. This probably wouldn't be the most efficient way of doing things, and you probably have some other special word to refer to what I'm talking about ("key derivation function" ?), but I never claimed my 5000 foot back of napkin design was meant to be comprehensive or final. Pay me for my time, and I'd be happy to learn your lingo and also provide a more specific, less wasteful solution. But at no point did I remotely expect or imply that anyone should use SHA256 in that manner.

Your response also tends to indicate you are, at best, a dick whose top priority is providing highly misleading statements in a clumsy attempt to cover for the gross negligence and incompetence of the people running your industry. But it's possible you're merely a sore loser, because by now you must realize that I was absolutely correct in everything I said and the only possible criticism you can have ultimately centers around the fact that I wasn't invited to the clubhouse to learn the secret handshake and codewords.

Re:Amazing Incompetence

[Anonymous Coward]

You can continue the ad hominem attacks all you like; it doesn't bother me much. You're still wrong. I'm still looking forward to further discussion on this topic with you, hopefully in a significantly more positive and constructive tone, so please reply to my last email when you have a few spare moments. In the interest of properly securing further email communications between us, I've given you my public key, and requested yours in turn. Thank for your prompt attention on this point, and I look forward to conversing with you again shortly. -PCP

Re:Amazing Incompetence

[Shane_Optima]

How about this: you tell me the word you know I'm referring to, and I'll go and replace "hash" with that word in every communication from now on.

A hash-like transform but without compression aspects. A "one way" transform that is very hard to reverse--toss a little RSA in here somewhere, I don't give a shit. The nuts and bolts of it wasn't the point; I implicitly and then later explicitly deferred that you people, the alleged experts too busy apologizing for gross incompetence to actually push for solutions. You and I both know that the properties I am describing here are achievable using known and freely available algorithms, without needing much more CPU than HTTPS already requires.

Re:Amazing Incompetence

[Shane_Optima]

actually I suppose the kicker is avoiding information leakage and collisions at the same time, right? That may be slightly tricker. But the fact is I never said SHA, and even if the word "hash" is entirely inappropriate you and I both know that the properties I am describing are achievable. You probably even have a word for it; you're just having too much fun to come out and say it.

Re:Amazing Incompetence

[Shane_Optima]

An ad hominem is not an 'attack'; it is an informal fallacy, and it is one I did not commit. You being a dick is a (tentative) conclusion, not a piece of supporting evidence used to reach some other conclusion.

And I'm probably unbearably arrogant. Not going to let that stop me. I find there is nothing LESS constructive in this world than slavish adherence to positive tones. Positive tones should follow positive content.

I'll get back to you with the key later tonight.

Re:Amazing Incompetence

[Anonymous Coward]

In the example programs I provided, you can replace SHA-256 with other commonly used algorithms, and you'll get very similar results. I'm still waiting for your reply to my email, but I'm keeping busy working on other things while I wait (ironically, most of what I'm working on right now involves cryptography and network security). I hope your evening goes well in the meantime. -PCP

Re:Amazing Incompetence

[Anonymous Coward]

An ad hominem is not an 'attack'; it is an informal fallacy, and it is one I did not commit. You being a dick is a (tentative) conclusion, not a piece of supporting evidence used to reach some other conclusion.

I wouldn't say my "being a dick" is a position that's supported at all by the content of our exchanges up to this point.

And I'm probably unbearably arrogant. Not going to let that stop me.

Maybe you are, maybe you aren't. Maybe it's an act. Maybe it's the result of a lot of understandable but misdirected frustration. I don't know.

I find there is nothing LESS constructive in this world than slavish adherence to positive tones.

I wholeheartedly agree with you on this point.

I'll get back to you with the key later tonight.

Thanks. -PCP

Re:Amazing Incompetence

[Shane_Optima]

I need more peace and quiet than is available at the moment to be able to properly navigate through the literature for the bits I need. Conversing is usually easier than absorbing unless the literature is of exceptional quality. Is there any you care to recommend?

For the key, I'll get back to you on that tomorrow. I haven't used GPG in quite a while. These days, it's hard enough convincing people to even use OTR. I'm doing something decidedly less pleasant than network security at the moment and it would actually be much quicker to get the proper concepts and/or terminology from one of you, if only one of you would drop this childish, pedantic elitism for just a few moments.

you can replace SHA-256 with other commonly used algorithms, and you'll get very similar results.

Uh huh. I'm afraid I can't quite let this slide--before we take this conversation private, I need to clearly emphasize just how ridiculous you're behaving.

As I've repeatedly indicated, I am a layman using goal-based working definitions, not technical process-based terms, because I am not (and never claimed to be) intimately familiar with the processes. I'm using "hash" as a shorthand for so-called one-way functions that are intended to obscure, i.e. with no need for symmetry or decoding but a strong need for it to be hard to reverse. I'm sure that "hash" means something very different to you. Congratulations. I knew that there was a distinction between "nonce" and "salt" too (and I even briefly brought up nonces in this thread long before you did), but that doesn't mean you have a legitimate point here. Ditto "hash" and whatever magical terms there are that you refuse to share with me.

You know... if I hear someone saying "clip" instead of "magazine" or "mag" I will sometimes correct them, but you know what I don't do? Pretend to not understand what they are talking about and then refuse to tell them the correct term. And if someone says "hey, the reason why that clip isn't fitting is it's backwards!"... the fact that you aren't actually holding a clip in your hand has very little bearing on the usefulness of their advice.

An astute observer might mention that there are subsets of this family of algorithms, having the strict stipulation of input sizes being less than the output digest size, which are referred to as perfect hashing functions. These are actually relatively rarely used for typical cryptographic applications, and for various good reasons.

I'm not sure if you could have ended that sentence in a more obnoxious manner, given the context of this discussion. (However, I'll go out on a limb here and say that it potentially leaks too much information about the input. Yes?)

That said, before I go any further, I do withdrawal my assertion (from a couple posts back, but not present in my original post) that provably zero collisions is achievable. I mean such transforms do exist, obviously, but perhaps not in a manner that is also sufficiently hard for an attacker to reverse engineer.

So let's do a bit of a test here to see how much intellectual honesty you're capable of. You and a lot of other people are caught up on the word "hash", even though I told you to feel free to substitute another word. Given your last few replies, the implication is that such a substitution doesn't exist and what I'm suggesting is inherently flawed and that *any* hashlike algorithm would have these issues. Well, ok then. I wish for you to tell me precisely what is wrong with this setup. I am not saying that this is what the final product would look like (I have no idea how it would look once optimized for efficiency), but it may give you a better idea of what I include under my umbrella term of "hash".

Plug the salt (or nonce or whatever you term it; I do_not_care) and password into a well designed crypto PRNG capable of generating a stream of numbers of arbitrary le

Re:Amazing Incompetence

[Anonymous Coward]

Take a step back for a moment. This isn't a personal battle of wills, at least not for me. I care about fixing useful things that become broken in some respect (sometimes this requires throwing parts out), taking things that are regarded as good and making them better (improved security margins against established categories of practical attacks, resilience against theoretical attacks, increased efficiency, cross-utility in other domains, etc), and preventing things which are broken by design from ever reaching environments where sensitive information would be put at heightened risk by their presence.

Bearing these points in mind, I hope you'll see that it's not going to do you, me, or anyone else any good to continue in the manner this thread as a whole has come to represent. Instead, I've simply replied to your last email with encouragement toward a better path. I look forward to the potential I believe can be found in that, and in the meantime I have only one suggestion to offer here: drink a beer. -PCP

Re:Amazing Incompetence

[Anonymous Coward]

Honestly. He's been spamming this in every thread to do with security lately. Worst of all are all the upvotes this nonsense garners from the equally clueless.

The whole argument is just fundamentally flawed anyway. All it boils down to "I'm lazy and want to reuse the same password. I don't trust you to protect me from my own lazyness server-side so do it... client-side!" like its going to be some magic bullet of accountability/auditability or something...

Re:Amazing Incompetence

[Anonymous Coward]

I gave you a bunch of objections the other day when you posted this same nonsense. Those you could understand you've assimilated into your suggestion above, without credit (e.g. hash it again on the server* - I hope I'm retrospectively awarded your $1000...).

Those you didn't understand - or were just too inconvenient to your argument - you've just omitted and will continue to discount in no-true-scotsman fashion (e.g. "lets ignore everyone who doesn't have JavaScript enabled and damn the business consequences!"). It's pointless debating with you, you just simply lack the knowledge or experience to see the cascading problems this causes and you're fundamentally just trying to brute-force your way through its flaws.

Your idea remains fundamentally broken. Even if it wasn't, its just a bad implementation of a problem solved in a much more elegant and secure manner elsewhere e.g. federated authentication. Your 'security bulletins, browser popups and corporate pressure' you've mentioned elsewhere is just... laughable.

* ironically missing the part where this is itself poses security problems if done incorrectly

Re:Amazing Incompetence

[Shane_Optima]

Nice try, but you didn't invent serverside hashing. I was merely clarifying that this wasn't intended to replace server-side hashing. The role that server hashes have only partially overlaps with the role of client-side hashes.

You didn't point out a flaw in anything. I never said my scheme was comprehensive or meant to take the place of anything.

Even if it wasn't, its just a bad implementation of a problem solved in a much more elegant and secure manner elsewhere e.g. federated authentication.

Don't give a shit. Implement that, then. Some other guy said that Kerberos fixed the problems I was talking about--use that, then. I never claimed this to be more than a 5000 foot back of the napkin thing written by a non-expert; nonetheless, it is provably much, much better than how most places are doing it. I don't have to be dog expert to know that your Chihuahua makes a shit guard dog. If my layman suggestion of "use a Great Dane" isn't ideal, I don't care; it's still objectively much, much better than the status quo.

Your 'security bulletins, browser popups and corporate pressure' you've mentioned elsewhere is just... laughable.

Uh, no it isn't. This is the non-technical aspect, and I assure you that a dozen industry professionals, people who had clout (and obviously would be using a refined version of this, maybe with challenge response, maybe some other very old idea that nonetheless address my concerns) using very aggressive shaming and security advisory techniques could easily change how things are done. None of this is particularly hard to implement in principle; there's just too much political momentum behind the current criminally incompetent way of doing things.

Incidentally, the client-side part of idea apparently has been independently thought of and implemented as a browser extension called Hashpass. I've not had time to examine this yet.

Re:Amazing Incompetence

[Shane_Optima]

"Every thread" == two different threads, apparently.

The whole argument is just fundamentally flawed anyway. All it boils down to "I'm lazy and want to reuse the same password. I don't trust you to protect me from my own lazyness server-side so do it... client-side!" like its going to be some magic bullet of accountability/auditability or something...

Everybody is lazy. Password reuse will happen regardless of training. Our computers are powerful enough to make what I'm saying trivial to do in principle, particularly in places where HTTPS is already used. I do not think the laziness of devs and admins should trump the laziness of users. As a general principle, I think that computers should remove as much of the burden from users as possible. I think that people who believe that users everywhere should do extra work and memorize more stuff instead of the devs doing a little extra work have no business whatsoever in the IT industry.

You might as well argue that the functionality to lookup and auto-dial phone numbers on cell phones is flawed and we'd all be better off if phone numbers had to be memorized.

like its going to be some magic bullet of accountability/auditability or something...

You may want to work on your reading comprehension. I am very, VERY clear that client-side hashing is not a magic bullet. It reduces the attack surface (by which I mean discovering the plaintext password without having to crack a hash) a little bit, but its main purpose is easy auditing. Other than those two things, serverside hashing is pretty much better across the board. I am further VERY clear that neither one will protect a weak password from having its hash quickly cracked.

Re:Amazing Incompetence

[Shane_Optima]

A comprehensive clarification of where I stand and what I claim can be found here: https://slashdot.org/comments....

I don't doubt that this is well-tread ground. I never claimed to be an expert. So, whatever existing product there may be accomplishes the same basic goals as my scheme--use that instead. My overarching point is that he status quo is not acceptable and that some form of client-side hashing (or pseudo-hashing) must be present to mitigate the potential incompetence of people running the server.

Re:Amazing Incompetence

[Shane_Optima]

I disagree with the current state of discourse virtually everywhere, and on virtually every topic. Insularity of experts and alleged experts, in both technical and non-technical fields, is one of the most daunting challenges that modern civilization faces and (when I can find the time) it's something I intend to explore at length. Part of the issue is what I call "The Inverse Bike Shed Effect", although there are a lot of other factors involved here, many quite sordid.

One tragic consequence of all this is that clear communication, including pointing out the flaws in the information that was just handed to you, is routinely mis-characterized as irrational or emotional communication, often even in the context of a debate. It is possible to purge all emotion while still conveying the same information, but this has the regrettable, almost invariable side-effect of causing critical information to be overlooked. You can be called boring or hysterically irrational, but never anything in-between.

I managed to retrieve your key (it appears that MIT doesn't take too kindly to VPNs) and will be emailing you shortly.

Re:Amazing Incompetence

[Anonymous Coward]

OK, from the sidelines: You seem much to enthused about this discussion for me to completely trust you. I have no serious knowledge of cryptography, but the fact that you're hammering this and it seems so IMPORTANT for you to be right says a lot.
It's like having someone tell you he likes beets,and you don't, then spends forty minutes telling you how great beets are. It goes from "whatever" to "um, i gotta go now and get away from this person" territory.

Posting anonymously, obviously.

Mayer for president!

[Anonymous Coward]

Anyone?

Excuses: Incompetence or Greed?

[Bob_Who]

I don't believe a word of it. If it were true, they would lie and say something else. Their only reason for announcing this is to manipulate the public opinion and to cover their corporate asses and branding. The fact is, if they announce a billion stolen passwords then I guess we no longer can accuse Yahoo of selling them, or the rest of the data mine that goes with it. And Verizon can't be blamed either, they never had control of the treasure. The timing of this announcement, to a degree of truthiness, was perfectly timed at the moment the Verizon deal was ready to go into escrow, perhaps. It is a hedge on public opinion when the customer realizes that somebody has sold them out: it was hackers. Yahoo would never dream of cashing in and selling you out, and neither would Verizon. That's why Yahoo and Verizon are transacting billions of bucks while hackers just transact a billion accounts and the customers wonder how many billion spam emails they received before criminals were involved. Its all conflated to firmly steer awareness you've been totally sold out, in violation of the promise to the customer, but its not their fault - the hacker's did it - its a criminal act, not yahoo's fault, because they are struggling incompetent boobs, and Verizon is so perfect a corporation that the hacker's only chance to get in was before the Verizon deal and security gauntlet arrived.

Double doody

Truth is the last thing that needs to be stated in the news. Everything is a paid advertisement, even the programming between commercials. We're the product when it comes to mass media. Do you feel like you've been screwed? Who pimps customer meat? We must be the human traffic.

Re:Fuvking mayer again.

[Anonymous Coward]

Sometimes people seem to forget how much therapy, top shelf liquor, and recreational pharmaceuticals can be purchased with a few million dollars. -PCP

SCRAM

[Anonymous Coward]

Take a look at https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism. I'm not sure it adds much (or even any) security to an existing secure channel, but it's interesting reading if nothing else.

Re:SCRAM

[Shane_Optima]

I haven't had time yet to digest it in detail but it is indeed interesting.

The one valid criticism of my ideas are that they don't go far enough; the instant I read 'challenge-response' in the article title I said to myself "oh, well, that's going to be even better." I don't claim to be the final word in these matters; I don't do this shit for a living. That doesn't change the fact that my recommendations are dirt-simple, low overhead, powerful and require nothing extra from the user (although they should still be using strong passphrases for maximum benefit.) If this basic idea can be made even better with a challenge response then by all means, let's do that instead.

This is like me noticing that firemen lined up using thimbles to ferry water to the scene of a crash. My suggestion to use buckets instead may not be the global optimum solution, but it is clearly a huge improvement.

Re:SCRAM

[Shane_Optima]

P.S. As I noted elsewhere, you've probably hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.

This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--you guys have a very limited understanding of how hashing can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.

Re:SCRAM

[Shane_Optima]

oops, please ignore the below reply. I meant it for another AC post.

All this work to steal...

[Anonymous Coward]

...accounts that could be created for free. The mind boggles...

Easy

[Ol Olsoc]

How many mail accounts does Yahoo have?

That's how many were compromised.

Small Claims?

[charliemerritt03]

IANAL, so, any around? How about a million small claims? Think Crypto Wars here: FBI's Comey said that they were waiting till next year for an "adult conversation about encryption" after collecting data this year. Collecting data? How 'bout a data point like: Poor Security = Enormous Financial Consequences. Fast. Did Yahoo encrypt everything, every connection? Could encrypting everything have been part of a comprehensive security plan? *I* didn't have a Yahoo account ;-) but if I did I think I just might head to the County Courthouse for a $200 filing for the hassle of needing to switch to Google.

You'd have to be on "LSD" to understand it...

[Anonymous Coward]

Those British with their silly walks and special units ...

Speaking as someone who's "British"- by dint of Scotland being in a union with Little England- I'll say that you have to love the way that Americans take the p*** out of units like "stones", yet rabidly defend all the other non-metric "English" units they retained in the face of decimal ones.

Interestingly, Americans seem to have a blind spot for the fact they use (and always have) a decimal currency system. It probably hasn't even occurred to most of them that it should be any other way- but then, that would probably be the case if they'd used metric weights from the start too. I find it odd that they retained all the inconsistent, non-metric English units, but didn't adopt the same non-decimal currency system that England (and the United Kingdom) used until 1971.

Granted, the "LSD" pre-decimal system was bizarre and confusing, and appeared archaic even to someone like myself who was born just five years after it ended, and it made perfect sense to get rid of it. But you'd have thought that Americans, with their love of those arcane, hard to work with, non-decimal "English" units would be just as enthusiastic about retaining this sort of nonsense as well.

Come on America- if you're so damn opposed to that commie decimal nonsense, why not ditch your decimal currency and adopt pounds, shillings and pence (240 of them to the pound, of course). And farthings, and thrupenny bits. And guineas. And.....