51–57 of 57 posts
Earlier quoted context omitted.
Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.
That's true currently of any HTTP-level logs
Earlier quoted context omitted.
It's interesting to look at? I don't think most people looking at the leaks are trying to profit (exception of people exploiting people based on the data). Ad systems however, are always looking at the data as a way to increase profits.
So violating people's personal privacy is okay if it's interesting to look at? I guess people who put hidden cameras in bathrooms feel the same way as you.
Earlier quoted context omitted.
It's interesting to look at? I don't think most people looking at the leaks are trying to profit (exception of people exploiting people based on the data). Ad systems however, are always looking at the data as a way to increase profits.
So violating people's personal privacy is okay if it's interesting to look at? I guess people who put hidden cameras in bathrooms feel the same way as you.
"There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay."
What differs between these two is that the ad system is the person placing the camera, watching the video and distributing. The interested person is simply watching the video. Sure that doesn't seem fair to the victim but if they are not trying to exploit the victim I don't think it's a problem.
Earlier quoted context omitted.
The elephant in the room is what you return when you SELECT. My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should sim…
If there are other ways to confirm whether a user exists or not (signup email check for example) -- I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.
Evening project: union Hello Kitty and Ashley Madison lists. No, some things are better left unknown.
I'm not sure what compels people to download and look at any of these leaks. There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay.
After previous leaks, the data has been looked over to produce lists of compromised accounts which at least one website lets you search to know if your account was in the leak (Kotaku/Gawker leaked my shit years ago). The data can be used to provide stats on the most common passwords.
> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works. I'd search myself but I'm afraid to find a "bad" tutorial.
The catch is one of "what platform are you using", as bindings are somewhat limited.
Earlier quoted context omitted.
Why is everybody immediately making these types of diversion responses regarding relational datastores to mongodb breaches? Mongo has popularity and 2 fixable issues that make the exposure numbers outweigh those of every other datastore right now. 1. There is no password prompt during installation. This was the same problem many relational databases had back in the day with default user credentials. Today, I don't kn…
I guess you could read my post as "others aren't better than MongoDB", but that wasn't my intention. I merely remembered the WEF anecdote and thought I'd mention it here (although it's unfortunate I didn't find an English source for it). MongoDB is repeating the same mistakes others made 15 years ago.
Sounds like we both agree that MongoDB is repeating the same mistakes others had made 15 years ago. The only difference is, back then, there was a less dramatic excuse for how it got that way.