Explain the significance of a password starting with "$1$" or not.
Here's what the "$1$" prefix means. Don't read anything more than this into the "$1$" prefix.
Originally, MtGox stored hashed passwords in their database. A few years ago, this was considered reasonably secure, but the development and distribution of "rainbow tables" made hashed passwords insecure. (A "rainbow table" is essentially a reverse-lookup which takes you from a hashed password to a candidate unhashed password.)
A few years ago, as in like 15?
In response to this, many websites (including MtGox) upgraded their systems to store salted hashed passwords instead of plain hashed passwords. This makes basic rainbow tables unusable for password cracking.
Again, the response to this was well before Gox was in operation. More on this in a bit.
The problem is: how do you upgrade the existing passwords to use the new salting scheme? You don't know the existing passwords; you only know their hash. So you wait until the user logs on with a password that matches the hash. At that point, the user has just entered their actual password so you calculate the password's salted hash, and store that in the database in place of the unsalted hash.
A common technique (which was used at MtGox) represents the salted hashes with a prefix of "$1$", to distinguish it from unsalted hashes and to identify the salting/hashing scheme.
The answer should have been; you don't, you friggin salt and shadow the passwords to begin with! That prefix technique would be pretty nifty if it were in conjunction with taking some sort of furthner action on the unsalted ones.
Case in point; About 14 years ago sadpanda owned a small hosting/dial-up firm. With roughly 2500~ dial ups, 500~ hosted sites and a partner who had the vision to monitize our userbase with our own "webmail". That was exciting, ad revenue and a new offering for our existing customers and potential new ones. There was one issue however and that was a big, fat unsalted password table.
Not long after we set the customer base up on the new webmail servers did we start to notice 'breaches' in the form of mails in customer inboxes that did not orginate from our mail servers. A good majority of which were trojan laced. We spent many a night integrating virus scanning on the mail servers and manually forcing customers with weak passwords to update them. A daunting task which would have continued to become a growing burden until I called an associate who himself owned a sizable hosting firm.
Skipping past the fee he wanted to come help my auditing efforts, he made short work of pointing out what I feel now should be obivous. It took him all of a few hours to exclaim, "Are these passwords unsalted and in their default locations?" Well, you by now know the answer to that. Just thinking about the implications of what that meant, not only in the immediate security issue but in what it would entail to get all those users to update their passwords, gave me quite the headache.
After a few days of manually fixing things I realized the only way to 'fix' it quick was going to be to update all the passwords ourselves. At this point we had added salt into our pwds and moved the storage of them to a shadowed format. And thats where we decided that we had no choice but to 'crack'(L0pht before they went legit) all the passwords ourselves and then push them through the salt. This would not patch up any one who had already been comprimised but certainly did put us in a posistion where we could stop chasing new breaches and focus on securing existing ones. Amen!
As an aside, the perps quickly became very unhappy about their lost playground and attempted to Ddos the piss out of our upstream. Unfortunatly for them we owned the exit nodes at our upstream and managed all the filtering ourselves.. ;p
tl;dr 14 years ago we began to salt and shadow on a system not used for financials and I would have assumed anyone setting up a secure system would have done so since then. :/
tl; dr: From the presence of the "$1$" prefix we can deduce that the user logged in one or more times after MtGox changed to salted hashes. From the absence of the "$1$" prefix we can deduce that the user created their account before MtGox changed to salted hashes, and did not log in to that account between that time and when the password file was leaked.
Sorry for all that off-topic wall of text. Those of us who reconize the salting realized what the $1$ was prefixed on the hashes.
Not to verify or disprove any of the 'research' Bruno has done here but the $1$ prefix does not remove what he had pointed out. If you look back at the mathcing passwords he showed, one being unsalted and the other being $1$ but with $1$
a , as what he was eluding to. I did not look at the pwd file to see if it is similiar past the
a but I am confident that Bruno did not assume every friggin password with $1$ in front of it was the same.
All that aside I personaly feel Tux has come a LONG way from where he started with this new venture and have not noticed anything as concering as the orginal issues. And, I definetly have to appluad his moxie in not giving in to the $7k extortion thing. That sounds like it could be quite stressing and possibly dangerous.
Now with the mybitcoin thing I can't help but feel, after listening to Hero's input that it sounds almost like some breaches started to become noticed and got out of hand before the orginal devs could do much about it. It seems like they were scared off by something and pretty much abandoned ship, leaving someone to deal with it pretty much on their own. Just my take on it now.
cheers everyone.
It is one of the largest hosting providers in Europe, but still I can't really fault anybody for drawing a connection on that point.
