Password security

White Horse Bricks

It seems that The Other Site has had a hack threat and is currently offline.

I assume that all the sellers with accounts on both aren't using the same password, but might be worth a precautionary change just in case the worst happens.

Malnaborg

Thanks for the notice.
Luckily i am no longer on that site, but maybe i should update the password here, just in case

Vosblokjes

Have different passwords
I see a message on FB that the hackers want money or they will be purging stores.
Strange thing is that they only give 1 hour to only which seems a bit quick, not sure if ot's real or not.

For all syncers, make a backup copy of the last backup. At least BrickSync makes a backup with every order that is placed

Malnaborg

Good idea to save a backup from the inventory here as well.
On my own drive at least :-)

SavioryBricks

It would be advisable to add to BrickOwl 2FA, just in case...

Malnaborg

And a good question, about general safety.

I can sell Lego other places, so it would not end me if something were to happen with brickowl.
But what and how brickowl is "secured" from something like this, would be nice to know 🙂

Hoddie

2FA doesn't change anything if the site itself is hacked.

SavioryBricks

Understand, but it doesn't change the idea of additional security. You can mess up a lot of things if you hacked the single account...

pippyblocks

It would be good to see two factor on both sites, it's not infallible but would certainly help reduce risk on user side.

Lawrence

Regarding 2FA, you can vote on the suggestion here https://www.brickowl.com/forum#/discussion/14255/account-security-2fa

Stores can manage their backups here https://www.brickowl.com/mystore/inventory/backups

Malnaborg

Nice. Have not seen that topic. And great to know you are into it Lawrence :-)

pippyblocks

Thanks Lawrence

Malnaborg

Just a thought. Since bricklink is associated with Lego.com
Maybe change your password at lego.com as well.

White Horse Bricks

@Malnaborg by all means change it, but even better, don't use the same pwd on both sites.

Bricks_nw_uk

I have forgotten where to change the password, can someone
link it please?

White Horse Bricks

Profile, then edit.

Malnaborg

Haha yes, different password 😁

lotsofbricks

Also, it's a good idea to use a password manager to create random long strings of characters for passwords. No one would ever guess something that looks like this: m7#sI@nE%xs&7wm$NQDK (not my actual password).

Brickingamazing

@Lawrence - would it be possible to have 'failed login attempts' added to the new user history page too per chance please?

Lawrence

@BrickingAmazing could you add that to the suggestions, we can then work that into our development schedule

Lawrence

@BrickingAmazing actually I've now done that. Just to clarify all the information shown in the user history was already logged in our general log, but is now kept seperately so users can view it.

Brickingamazing

Thank you for the swift change - works like a charm.

tiesontrowbridge

@lotsofbricks Most passwords are "cracked" using bots and rainbow tables (and the kind of GPU racks you typically see in crypto farms). A password that's just randomly generated is actually a bit easier to brute-force than one created manually using a good mnemonic.

Not to say that I disagree with leveraging a password manager - anything that keeps someone from writing passwords down or reusing the (more or less) same password on multiple sites is always a win.

Hoddie

^ doesn't that presume that the site allows you to make an infinite number of attempts at the login stage before saying "nope!"

tiesontrowbridge

@Hoddie Statistically speaking, few hacks are done via automation against a website. Normally it's a case where the database itself has been compromised, so the cracking is done against an offline version of that. Once the passwords have been reverse-engineered (not decrypted - passwords are hashed, so as a hacker, you're trying to determine a clear-text password that yields the same hash, using well-known hashing algorithms), the attacker is just acting as a normal user (admittedly, not doing nice stuff at that point).

Hoddie

But that's the point - if your password is simply a pseudo-random string of letters, numbers and punctuation marks, there will never be a human-readable "clear text" reverse of a password, and if you're trying to brute force all the possible reverses that aren't human-readable, you would hope that the website steps in after a couple of failed attempts. I'm not familiar with the tools available to hackers, so it's possible I'm well off the mark, but a hash will yield multiple possibles, at which point you have no choice but to brute-force - unless, of course, one stands out because it says "disneyPrincessArielisCute" or something.

tiesontrowbridge

> you would hope that the website steps in after a couple of failed attempts

This assumes that you're submitting passwords against a login page. That isn't how password cracking works (well, not for any real threat as a hacker). The general process is:

1. Hacker(s) obtain a copy of the database.
2. A lot of organizations fail to encrypt their databases at rest, so anyone can read the values stored in the database.
3. If there's a Users (or similar) table, there's one half of what's needed to access a user's account - their username. The next part is where the work begins - trying to determine what hashing algorithm was used to create the password hashes.
4. Using rainbow tables of common passwords (which usually includes previously-compromised passwords from other sites), a script will churn through the plaintext passwords in the rainbow table, hashing them and looking for the same hash in the stolen database. GPUs can repeat this process millions of times in a fairly short amount of time, so if the site used a fairly simple hashing algorithm (especially if it wasn't a hashing algorithm INTENDED for password protection), it's going to find matches within days, if not hours.

So, as an example, if I use, say, SHA1 on your "disneyPrincessArielisCute", I'll get a hash like "qe++n1dD6nx33wPuHE/PxnkTO1s=" when converted to Base64. If I see "qe++n1dD6nx33wPuHE/PxnkTO1s=" in a password field, then I now know that your application uses SHA1 as it's password hash and that your application doesn't salt (and hopefully pepper) user passwords. After that, I can just run my racks of GPUs against my copy of your database until I've found as many passwords as I want.

Does a user's password which is made of a randomly generated string require more work to recover? Sure, but not that much more. No random generator in any programming language is truly random, and if I'm a real threat as a hacker, then I know the most popular password generators and how they generate passwords, so I can create (or use) lists of probable passwords as part of my cracking routine.

Apologies if I'm coming off as a know-it-all - that's not my intent, nor am I any sort of expert. This is just stuff I have to be aware of and guard against as a software developer, and I generally assume it's better have some idea how stuff like this works than not.