Thingiverse Data Leaked — Check Your Passwords

Every week seems to bring another set of high-profile data leaks, and this time it’s the turn of a service that should be of concern to many in our community. A database backup from the popular 3D model sharing website Thingiverse has leaked online, containing 228,000 email addresses, full names, addresses, and passwords stored as unsalted SHA-1 or bcrypt hashes. If you have an account with Thingiverse it is probably worth your while to head over to Have I Been Pwned to search on your email address, and just to be sure you should also change your password on the site. Our informal testing suggests that not all accounts appear to be contained in the leak, which appears to relate to comments left on the site.

Aside from the seriousness of a leak in itself, the choice of encryption should raise a few eyebrows. Both SHA-1 and bcrypt can be considered broken or at best vulnerable to attack here in 2021, so much so that for any website to have avoided migration to a stronger algorithm indicates a very poor attention to website security on the part of Thingiverse. We’d like to think that it would serve as a salutary warning to other website operators in our field, to review and upgrade their encryption, but we suspect readers will agree that this won’t be the last time we report on such a leak and nervously check our own login details.

40 thoughts on “Thingiverse Data Leaked — Check Your Passwords

  1. Given the difficulty in getting anything fixed on that site, it’s really not surprising that they’ve had a breach. I think the more surprising part is that it hasn’t happened sooner.

  2. There should be a static website with all the passwords ever leaked, not a search engine to tell if an email address is in the leaked database of passwords.

    That would motivate more people to change their passwords :-)

    1. They [] have made it into a search to order to protect you or others.
      I have been in the habit to create an email address and password for every service I use, so I can easily block, if needed. but yeah u/p is a bit oldfashioned.

      1. And it is quite interesting how they accieve Cheackability without transmitting the secrets in plugins like for Keepass:
        – They take your input from the website-search-form
        – They enctrypt this string on your own computer
        – Still on your Computer they REMOVE most of the string apart from something like the last 10 bytes or so
        – This information-fragment is then sent to the servers of HIBP
        – The server does a search of this truncated string against all its entries, which have been enctrypted the same
        – If it finds any match, it sends back the complete encrypted hash to you. (You will receive maybe 100x the hits than you would expect as your hash only needs to fit partially to another has as we removed a large portion of the hash)
        – Your computer checks the delivered, complete hash with the calculated (but not sent) complete hash of your PW / eMail
        – Your computer knows now, if your PW (hash of) is in the DB or not without releasing the PW or a complete hash of your PW

        The same will propably happen on their website…


      2. This is a great move if you have your own domain. Dump all uncategorized emails into one bin, make them up on the fly like “website name @ your domain”, and you’ll know which website was leaked if you get spam

  3. So my e-mail shows up as leaked, and I try to log in to change it:

    Anyone else getting this?

    It was, frankly, a crappy low-value password, and if they really used _unsalted_ hashes on them (in 2020!) then it’s probably fallen to any competent password cracker by now.

        1. Same here, including that crappy UI.
          I found it somewhat strange that the password change didn’t trigger some kind of verification. A bad guy could possibly take full control of leaked accounts, lock out the legitimate owners and post nasty things, without alerting anyone.

    1. This is precisely why I “noreply+EXPECTEDORIGIN@MyDomainName.tld” for every website. If it doesn’t come from [EXPECTEDORIGIN].tld then you know which domain has been breached. Should they wise up and send only to “noreply” then it is goes to /dev/null.

    2. There is good reason why the groups are now moderated. Its due to robo-spammers responding to posts with hacked software licenses, movie, porn, etc. I posted a question in one of the groups last week and replies started swarming in from these asshats.

    1. It looks like the leak was in the form of a database backup archive, and there are ways of getting that without having complete control over the site.

      On top of that, an attack using malicious STL files (maybe exploiting a flaw in a popular slicer?) would be both novel and complex. Far above the heads of the kind of punks who go around selling db backups

    2. Malicious STLs seem a bit scary actually (although very very unlikely).
      Given a slicer exploit, a printer lacking some safety features and a careless user that doesn’t monitor the print, it could potentially make a spaghetti monster for fuel and then set it on fire…

  4. My account popped up as being leaked, so I went ahead and changed my password even though Thingiverse has communicated exactly nothing about the whole thing. They may think that since the passwords are hashed it’s not a big deal. I disagree. Makerbot has pretty much ALWAYS been a PoS run by PsoS. Thingiverse is useful, but ONLY because of the community that contributes to it freely.

    May be time to back up all of my projects on there one last time just in case I lost any local copies. I’m not sure they’re going to last much longer anyway.

  5. It seems like there is almost no consequence for these companies when data gets leaked or lost. Maybe they would take a little more care with this data if they had to individually compensate every user who had their data leaked.

    1. I still think, since the age of myspace, that it’s criminal for a company to use unsalted passwords.I think every company dealing with user data should have to secure it as best as possible, or face harsh penalties. It’s not rocket science, just 10 lines of code, literally.
      Throwing the responsibility onto users “use a unique password” is lame.
      If there were monetary consequences, I’m sure companies would quickly adjust. Or just use google or facebook (shudder) authentication, there are so many safer options.

  6. It’s misleading to say that bcrypt is broken. Bcrypt is used widely for password hashing (along with PKDF2, and some scrypt) because it allows for a variable time constant – this *should* be used to strike a balance between security and response time.

    The source article of the linked bcrypt article suggests that 18 of their FPGAs can do 2.1 million hashes per second, when the bcrypt time constant is 5. That’s 2^5 = 32 iterations of Blowfish. But the source article also mentions the critical point that in the wild, the work factor is usually larger, between 7 and 14. That’s 2^7 – 2^14 iterations, or 128 – 16384! Many libraries, such as the Node.js npm package bcrypt, and php’s password_hash default to 10, so that’s 2^10 = 1024 iterations, which is orders of magnitude greater than the 32 iterations with which the benchmark was run. So bcrypt as a password hashing scheme is definitely not *broken*.

    SHA1 on the other hand, yup, absolutely should not be used for passwords. A single RTX 3080 can do about 16000 million hashes per second of SHA1.

  7. There is nothing wrong with bcrypt, properly used. In fact I still consider it to be the strongest password hash currently available for a target of 0.25 CPU-seconds or less on the server.

    It also can’t be literally true that a bcrypt hash is unsalted, but if they used a well-known hash and too low of a cost parameter, then yeah, those are real issues.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.