|
I like the comments. This person could have gotten 2k in bounties! Microsoft bounty program is such poo poo.
|
#
?
May 23, 2019 20:40
|
|
|
|
| # ? May 13, 2024 14:56 |
|
|
Sickening posted:I like the comments. This person could have gotten 2k in bounties! If this is the same person, sometime last year she got stiffed on a bounty program, had a twitter meltdown and failed to auction off a zero-day.
|
|
#
?
May 23, 2019 21:05
|
|
|
Pretty sure there’s some declared mental health issues and a proclamation to quit the industry in there as well. Fun times. I hope she gets the help she needs prior to getting arrested.
|
|
#
?
May 23, 2019 21:27
|
|
|
Apparently Google is being sued due to the 'someone has signed into your account' false positive that triggered thousands of people-hours in various company security teams? Apparently Roche freaked the gently caress out, and they're huge.
|
|
#
?
May 23, 2019 21:42
|
|
|
Maneki Neko posted:I've seen some rumblings of proof of concept vulnerabilities out there for the big ol' RDP bug that was patched recently, anyone seen anything public? Nope. This got my boss all up in a tizzy about it but I looked at MS's pre-patch mitigation and it was a big list of poo poo you should already be doing. Then I patched the servers.
|
|
#
?
May 24, 2019 01:15
|
|
|
Sickening posted:bounty program is such poo poo.
|
|
#
?
May 24, 2019 01:18
|
|
|
"You'll get no bounty and we'll sue you if you release it"
|
|
#
?
May 24, 2019 02:38
|
|
|
Sickening posted:I find it disturbing that someone even assumes they can take an employees personal property. LOL, yes. No, you can't have my phone. If you touch me, we're gonna fight, and then I am going to press charges and sue the gently caress out of you. Not to mention that if your BYOD setup is so weak that you need access to a personal device to ensure nothing's walking out, you're already hosed.
|
|
#
?
May 24, 2019 17:09
|
|
|
https://twitter.com/briankrebs/status/1132026003386241029 ouch
|
|
#
?
May 24, 2019 22:16
|
|
|
Got this email from Flipboard but their explanation of how secure their password storage just got me.quote:
We def did not use a algo that has rainbow tables out there since forever. And who wants to bet it was only one round of sha-1?
|
|
#
?
May 29, 2019 19:01
|
|
|
EVIL Gibson posted:Got this email from Flipboard but their explanation of how secure their password storage just got me.
|
|
#
?
May 29, 2019 19:31
|
|
|
EVIL Gibson posted:Got this email from Flipboard but their explanation of how secure their password storage just got me. Sounds like they stopped doing it in 2012 though, and if they salted uniquely that was pretty much state of the art AFAIR. E: ^^ 
|
|
#
?
May 29, 2019 19:32
|
|
|
Otoh they should have converted existing users to bcrypt on login, rather than waiting for a password change. They could have minimized the damage to people who haven't logged in since 2012.
|
|
#
?
May 29, 2019 19:34
|
|
|
Volmarias posted:Otoh they should have converted existing users to bcrypt on login, rather than waiting for a password change. They could have minimized the damage to people who haven't logged in since 2012. Yeah, on login is much better, and after say 5 years absent I think it's reasonable to forcibly reset someone's password if it's in a weak format.
|
|
#
?
May 29, 2019 19:49
|
|
|
They needn't wait for login even, just bcrypt the existing mess and set a flag somewhere to commemorate it
|
|
#
?
May 29, 2019 20:22
|
|
|
Wiggly Wayne DDS posted:sha-1 with unique salts isn't nothing to sniff at for pre-2012 storage, what do you expect a rainbow table to help with there? would a million rounds of sha-1 be preferable? ah. missed the salt part for some reason. well, at least someone only has my email then i guess Rufus Ping posted:They needn't wait for login even, just bcrypt the existing mess and set a flag somewhere to commemorate it what would they bcrypt ? there's no passwords for users that have not logged in. just sha-1 hashes and a salt. if you want to confirm the users coming back are the user, the old hash is the only thing to confirm identity besides email and possibly the tokens to see if the user is still the user on facebook or whatever. EVIL Gibson fucked around with this message at 20:46 on May 29, 2019 |
|
#
?
May 29, 2019 20:37
|
|
|
EVIL Gibson posted:what would they bcrypt ? there's no passwords for users that have not logged in. just sha-1 hashes and a salt. in other words Rufus Ping posted:They needn't wait for login even, just bcrypt the existing mess and set a flag somewhere to commemorate it
|
|
#
?
May 29, 2019 21:44
|
|
|
EVIL Gibson posted:what would they bcrypt ? there's no passwords for users that have not logged in. just sha-1 hashes and a salt. for old users, bcrypt the old sha1 hash and keep the old sha1 salt beside it. add a new field "is_old_hash" and set it to true on login: - if "is_old_hash" == false then do your normal bcrypt thing - if "is_old_hash" == true then check whether saved bcrypt_hash == bcrypt(sha1(old_sha1_salt + password_guess)) - - if false deny access - - if true replace bcrypt_hash in db with bcrypt(password_guess) and set is_old_hash=false edit: then at some point in the future delete the old_sha1_salt field and force a password reset for everyone out who has is_old_hash==true Rufus Ping fucked around with this message at 22:32 on May 29, 2019 |
|
#
?
May 29, 2019 22:23
|
|
|
Rufus Ping posted:for old users, bcrypt the old sha1 hash and keep the old sha1 salt beside it. add a new field "is_old_hash" and set it to true Just confirming this is the best way to do it. Your post i originally quoted could be taken (like i did) as simply deleting all hashs /salt blindly reset all passwords when the original sha1-salt is a good verification if people have it. Doing that is still an acceptable way, nevertheless. Rufus Ping posted:They needn't wait for login even, just bcrypt the existing mess and set a flag somewhere to commemorate it I didn't want people to think the sha1/hash is bad but as still a good verification until the certain date where all people that did not update their password would just be reset completely and their old hashs dumped.
|
|
#
?
May 29, 2019 22:41
|
|
|
EVIL Gibson posted:Just confirming this is the best way to do it. Your post i originally quoted could be taken (like i did) as simply deleting all hashs /salt blindly reset all passwords when the original sha1-salt is a good verification if people have it. Doing that is still an acceptable way, nevertheless.
|
|
#
?
May 29, 2019 22:58
|
|
|
EVIL Gibson posted:Your post i originally quoted could be taken (like i did) as simply deleting all hashs /salt blindly reset all passwords when the original sha1-salt is a good verification if people have it. I'm having difficulty understanding your post but I believe you are referring to the system Volmarias/Subjunctive mentioned: add a new field "is_old_hash" and set it to true for everyone. *but do not modify any hashes at first* on login: - if "is_old_hash"==false then validate password using bcrypt - if "is_old_hash"==true then validate password using sha1 - - if successful then replace hash with bcrypt(password_attempt) and set is_old_hash=false EVIL Gibson posted:Doing that is still an acceptable way, nevertheless. not really. it is worse than the method i posted. this is because your db still contains sha1 hashes for the duration of the changeover. this is not necessary and is a liability (this is why you're upgrading your hashes! you don't want weak ones in your db)
|
|
#
?
May 29, 2019 23:03
|
|
|
I don't think that's it. I think what they're saying is: 1. Add new fields "is_old_hash" and "old_sha1_salt." 2. Set the former true for everyone and store the salts in the latter. 3. Bcrypt all hashes in the old password fields. Your database now contains no sha1 hashes. 4. When someone logs in, if is_old_hash is true, hash their password with the sha1 salt, then bcrypt it. 5. Compare the bcrypted hash to the stored password. If they match, bcrypt the regular unhashed password and overwrite it in the database, then set is_old_hash to false. 6. After a few years, delete all is_old_hash passwords from the database and force anyone for whom the flag is still true to reset their password.
|
|
#
?
May 29, 2019 23:11
|
|
|
Cup Runneth Over posted:I don't think that's it. I think what they're saying is: that is what i was trying to describe in my earlier post. if Evil Gibson was trying to describe my method back to me, his understanding is correct
|
|
#
?
May 29, 2019 23:13
|
|
|
Oh, my bad. You guys are better at infosec than visual design so your ASCII flowcharts were a little confusing. On another note, the Twitter accounts this thread recommended a few pages ago are now fighting over Dave Aitel. Who do I root for?
|
|
#
?
May 29, 2019 23:16
|
|
|
Rufus Ping posted:that is what i was trying to describe in my earlier post. if Evil Gibson was trying to describe my method back to me, his understanding is correct if the plan is improving the security why are you wasting energy assuming your database has been hacked rather than stopping it in the first place? it's these practices that plague the industry
|
|
#
?
May 29, 2019 23:17
|
|
|
Cup Runneth Over posted:On another note, the Twitter accounts this thread recommended a few pages ago are now fighting over Dave Aitel. Who do I root for? allow me to consult the "number of oil powered urinals in his bathroom at home" league table. ok the answer is big dave
|
|
#
?
May 29, 2019 23:33
|
|
|
Wiggly Wayne DDS posted:but your idea is fundamentally broken. there's been enough stories of even google trying this approach and it resulting in password breaches because they had to log it for compliance purposes How is that broken? I can't think of a way that bcrypting a salted password hash would be somehow less secure than leaving a shitload of SHA1 passwords sitting in a database somewhere.
|
|
#
?
May 30, 2019 00:10
|
|
|
Here’s Alec Muffett, two decades after Crack 5, talking about how FB does scheme migration and various other tricks: https://youtu.be/7dPRFoKteIU (Did then, at least, but I haven’t heard of material changes and I don’t think they’ve deployed any SGX bullshit yet.)
|
|
#
?
May 30, 2019 00:16
|
|
|
I expect Harley Davidson to have a conference on rider safety with Evel Kneivel as keynote any day now.
|
|
#
?
May 30, 2019 23:20
|
|
|
AlternateAccount posted:I expect Harley Davidson to have a conference on rider safety with Evel Kneivel as keynote any day now. Oh my god no.
|
|
#
?
May 31, 2019 02:32
|
|
|
I hear her talk will about managing and securing shadow email.
|
|
#
?
May 31, 2019 02:41
|
|
|
i wish she would just go away
|
|
#
?
May 31, 2019 03:31
|
|
|
I mean, giving a keynote at FireEye is kind of like going away.
|
|
#
?
May 31, 2019 04:18
|
|
|
FireEye still has a shitload of government business despite their public failures. Helps to know some senators if you want to get big.
|
|
#
?
May 31, 2019 22:36
|
|
|
Anyone else going to Cisco Live next week?
|
|
#
?
Jun 1, 2019 23:35
|
|
|
Well, had my meeting as the new guy, meeting with the new director. I took the opportunity to discuss the fact that all of the credentials needed to access millions of rows of legally privileged client information in SQL databases are stored in plaintext on Sharepoint. Turns out there was merit to my thought of the new director having less inertia than the people who have been here for a decade+. He was absolutely shocked, and plans to talk about it with the new infosec VP I forgot started a couple weeks ago. I suggested a password manager and namedropped Hashivault as an option. I mentioned how they already use Keepass for something else but I don’t like how it shares a password between everybody. He actually said they’re working out budgets for projects so maybe they will even be interested in some not halfassed solution. I don’t know what kind of person the InfoSec VP is, but I really hope I haven’t made any enemies bringing that up. Considering that one of the 10+ year inertia people is my direct manager.
|
|
#
?
Jun 3, 2019 23:22
|
|
|
Its really not a good idea to rock the boat right away. Even something as dumb as that. Humans are just weird and its usually always better to right it down and revisit it in the near future.
|
|
#
?
Jun 4, 2019 00:12
|
|
|
Sickening posted:Its really not a good idea to rock the boat right away. Even something as dumb as that. Humans are just weird and its usually always better to right it down and revisit it in the near future. Are you the guy that got a bunch of people, rightfully, fired within like a month of joining a new company?
|
|
#
?
Jun 4, 2019 00:21
|
|
|
PBS posted:Are you the guy that got a bunch of people, rightfully, fired within like a month of joining a new company? True. They were people who report to me and reading the C level email is a big deal. I wouldn't put those two things in the same category. I could have gotten fired for not take action the way I did. Sickening fucked around with this message at 00:27 on Jun 4, 2019 |
|
#
?
Jun 4, 2019 00:24
|
|
|
|
| # ? May 13, 2024 14:56 |
|
|
Sickening posted:True. Fair enough
|
|
#
?
Jun 4, 2019 00:25
|
|