However you store them, it is a database. And there's actually nothing wrong with using a relational database for that. (Of course, you don't store passwords, but salts and salted hashes.)
Of course there is nothing wrong with using a relational database. My concern was about storing passwords in it. There is a difference between storing passwords and storing hashes and/or salts.
In general, you don't. You store hashes. Exceptions sometimes apply when it's a credential used to access some other system - for example, Plaid's gonna have to store your bank account password to scrape it - but there you'd at least hope for encryption.
Media coverage tends not to get the distinction right, so it's always hard to tell if the company fucked up or the attacker is exaggerating on early coverage.
(Assuming this is what you meant by *but there you'd at least hope for encryption*, but expanding to verify): Even in this case, it seems unreasonable to store the password. Rather, the user's Plaid login should act as a part of multi-token access setup, where Plaid's backend services' tokens can also be used to decrypt the user's credentials in order to authenticate to those other service.
In short: even then, storing plaintext passwords seems... like choosing convenience for security, and that seems very wrong.
The article states "the group provided 100 credential pairs". That indicates one of a couple things; a) lying attacker providing old hacked accounts, b) unsalted or weakly salted credentials vulnerable to rainbow tables or brute force or c) plaintext storage.
Or it's just credential stuffing matching email with plaintext passwords from other old breaches, or they created 100 accounts and thus know the password, etc.
Until a more detailed investigation/write comes out it's difficult to say for certain what they have, if anything.
It could also be colloquial use of "credential pairs." In that it could be that they were, in fact, hashed; but the report went with a quick verbiage to say they were leaked. Especially considering that most hashing/encoding tricks will go out of date and many common passwords will still be as effectively leaked.
No a one-way hash is not "the password". If you have the hash you can't use it to login or reverse it to a password without brute force comparison which is why you always store a hash with salt using slow hashing algo, and not "the password", this has been best practice for years so a DB breach does not mean the password are compromised.
I agree, but it's still the password in that it's the secret set of characters needed to be compared against to login. It's just not the same text a user would enter when prompted for the password.
Keeps in mind these hackers are the ones saying they have passwords and this is Microsoft. Most likely hashes.
Be warned that this makes your authentication system less secure because it caps the maximum entropy of the password to the entropy of the hash function.
You need crazy long passwords for that to become the limiting factor. With random printable characters on the keyboard there are a bit less than 7 bits per character (unless a crazy amount of different accents are used). So you need passwords longer than 18 characters to surpass the entropy of even MD5.
A simple change if you don't want to change it too much eg. moving away from passwords would be to use a sponge function instead of a hash and and squeeze out the same number of bits as the plaintext.
Good point. How about splitting the password into chunks, then use a key streching algorthim on each chunk with difficulty tuned to be easier based off the total amount of chunks, and concatenating them.
That doesn't prove anything. What it does clearly prove, though, is that the Earth is flat. Think about it: have you ever successfully landed with a parachute on a spherical object like a soccer ball or large marble? See?
The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over.
In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives.
Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are.
(36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)
> The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over.
And you missed your window to get into BIOS, you need to reboot and try again. /s
And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen?
Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways.
If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes
Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ...
And that's a lot of round trips whereas they could have done:
Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ...
That was my first reaction too. However, unlike the no-SQL monstrosities (like Mongo), this one seems to sit on top of a proper relational database, plus it seems to follow all the ol' good data modelling logic, just in a modern ish way, so I think it looks promising.
I'm not going to switch all my clients to it next week :) But it is definitely on my radar.
Whoa, this is a great resource. Never heard of it before, it looks like I'm finally able to get some proper book recommendations. Absolutely loving it.
Weird though that for certain cases it spells English author names with Cyrillic alphabet. Like for instance when I center the graph on "Stanisław Lem", I can see names like George Orwell or Terry Pratchett spelled in Cyrillic. I wonder why.
I actually enjoy Dropbox - for a flat fee of ~€10/month I get 2TB of cloud space plus the synchronization across unlimited devices. I don't mind the telemetry thing, at least not too much.
However, their approach to Android is absolutely ridiculous. There is no files or folders synchronization - at least not at the OS level, like in Windows or Linux. If I need to access my Dropbox files on an Android device, the only way is to do it via the Dropbox app, and it is clunky. The biggest pain point is that I cannot use 3rd party apps to open a folder in my Dropbox storage - I can open a single file, fine, but for example Obsidian is out of reach as it requires opening an entire folder, which is currently not possible.
(I can create an offline copy of the folder on the device and open that one but it defies the purpose of having a sophisticated synchronization software).
So I think at some point I will start investigating alternatives.
Certain operations use fewer resources when performed in the RDBMS than when performed in the application code.
As your data grows significantly, you may encounter new bottlenecks, and for some of these you may need to move some of the logic from your application into the RDBMS (ergo: write an SQL function or a stored procedure or a trigger, etc.).
A database containing passwords? Why would anyone store passwords in a database is beyond my comprehension.