LogRhythm | Boulder, CO (main) | Maidenhead, UK | SoCal | Texas | Mountain West | Minnesota | North Carolina | Central & Eastern Europe | ONSITE & REMOTE
* JavaScript UI Dev, Software Engineer, Software Engineer Intern, Software Engineer Tier IV, Software QA Engineer [Web], Software Engineer Team Lead - Boulder
* Information Systems Manager, Service Desk Tier III - Boulder
* Senior Security Research Engineer - Boulder
* Senior Product Manager - Boulder
* Support Services Engineer Tier III, International SIEM Technical Trainer, Security Professional Services Consultant – Maidenhead
* Courseware Developer, Senior Professional Services Consultant, SIEM Technical Trainer, Support Services Manager: Tier I, Support Services Manager: Tier II - Boulder
* Various types of Sales Engineers - DC, SoCal, Texas, Mountain West, Minnesota, North Carolina, Maidenhead, Central & Eastern Europe (all OFFSITE I believe except maybe Maidenhead)
LogRhythm is a security intelligence software company focused on threat detection and security analytics. Interviews vary by position. For engineering positions at least, you will be asked questions related to your purported experience and knowledge (per your resume and phone screens). You will probably get at least one design question, at most one programming problem and maybe a hypothetical troubleshooting/debugging question.
Okay, I don't get it. They took an already NSFW image and ran it through deep dream with layers from the Yahoo NSFW model and made actually less NSFW images?
>It was a monologue about the right to exploit the stories of “others”, simply because it is useful for one’s story.
I thought the talk was about fiction, which by definition is made-up stories, so how could they exploit the stories of others? Stories of other people would be non-fiction. I'm guessing the quotes around "others" is the key to the mystery here.
"Others" in this context refers to your out-group. For example, if I am a straight white male, then it is kosher for me to write a fictional story about fictional straight white males because they are part of my group.
But if I try writing about a fictional gay black women, then I am exploiting the groups of gays, blacks, and women.
> exploiting the groups of gays, blacks, and women
Ok, that I can follow (I don't really agree with it). But what she said was "exploit the stories" of your out-group. Since the work is fiction it's nobody's story. Not my group's nor my out-group's. I guess the claim is your "group" retains the exclusive right to produce works of art that feature a fictional representation of someone or something related to your group.
The whole "cultural appropriation" thing is, essentially, an assertion that there's some kind of implicit intellectual property like relationship that one has with one's culture and its collective experiences. So when you need to "use" a culture that's "not yours", you have to ask for permission, and conform to the rules that the other party frames their grant of such around.
That opinion piece in The Guardian was quite a read - a real view into how some progressives think. It was also mercilessly slammed in the comments section, which gives me hope that the dogmatic excesses of the left will not prevail.
Yeah, they shouldn't have unprotected passwords in any way, shape, or form. The statement makes it sound like they do store unprotected passwords, but they don't think those were stolen.
Is that good? They have poor data handling and sunsetting protocols is what you're saying.
UK law requires that personal data is not kept for longer than is necessary and is securely handled and such. So if those passwords in an "ancient DB" had personal data associated with them (real names, say) then they've been breaking the law (for a long time, is the implication).
Surely if you had passwords in old DBs then when you introduce hashing you salt and hash them and sanitise the DB and all backups ... having them still hanging around is a significant failure too. But yes, not as significant as having plaintext passwords in DBs now would be.
Interesting point on the UK laws, but I doubt PII is kept alongside login data, just referenced, and removed as needed without removing a user's login credentials.
Far from an expert, but hasn't flagging an account as needing a password change on next login been used as a way to migrate to properly encrypted passwords in the past?
Often. But you want to back it up with a blanket invalidation and password deletion after some grace period, to deal with the case where the user just never logs back in - and a password reset process outside the auth flow, to handle anyone who comes back after that.
A strategy that has worked great for me transitioning off of poorly-thought-out legacy password storage schemes is to take the "bad" hash you have for everyone and treat it exactly as you would a plaintext password - in other words, salt and properly hash it the same way the new passwords are done. Then I delete the unsafe hash and flag that account as "use the old hashing scheme on the password first before normal authentication process, then correctly re-hash and salt the password and store it normally."
Not passively anymore: login.yahoo.com is negotiating PFS ciphersuites which the private key can't decrypt without a copy of the ephemeral ECDHE parameters.
I personally don't care what you consider to be an engineer. I solve engineering problems, and I solve them well and I get compensated for it. I want to create great physics systems in game engines. It's not my problem to solve to make games built with that engine a success. I want it to succeed, but I don't get involved. That's not what I'm good at.
A four year degree is a certification. What would a "real certification" do differently to make it "real"?
> would simplify interviewing and reduce the "whiteboard hazing"
I doubt it. If a certification is too specific it'll exclude an enormous amount of engineers. Make it too broad and then companies will still have to do the same interviews they do now to verify that a person is a good fit for the specific job opening they want to fill.
I'm eager to hear your proposal on a certification method that doesn't exclude wide swaths of existing and future engineers based on your specific definition of what a software engineer is and isn't, but at the same time is specific enough that having the certification actually means something to other people.
Proof that they're not pointless: The adobe password leak. Other than the giant crossword puzzle[0] created by the password hints combined with their choice of ECB mode to encrypt the passwords that allowed people to infer blocks of passwords, I haven't been able to find any evidence that the encryption key was leaked or guessed. So, most of the passwords were never discovered. I'm betting their key was a full 168 bit random value that was immediately deleted when the leak came to light, so it's likely that value will never exist again in this universe. Compare that to something like LinkedIn (SHA1) where enthusiasts have cracked almost 97% of the passwords in that leak. How many more have blackhats cracked?
I certainly wouldn't rely on symmetric encryption alone to store passwords. If the password leaks, you expose all passwords in mere seconds. Plus you can see your user's plaintext passwords (since you have the key), which you should not be able to do. But as an extra measure symmetric encryption has already proven itself to be useful.
