Not too surprising. From a technology and hacker standpoint, I had a run-in with one of their earlier developers that left a really bad taste in my mouth.
An ex-engineer from Yik Yak reached out while we were hiring a while back.
They proceeded to supply a .zip file of their entire source code repository (yes, all of it). They said it was outdated now so it seemed okay in their eyes.
This included all of the dot files for configuration: keys, passwords, email addresses, Amazon instances where databases were at, and more.
I didn't ask for this .zip file, I was simply looking for some examples of experience.
Needless to say, it definitely made me look at Yik Yak differently.
Is it really wrong to give architectural considerations of the security of a system? It seems like security is a problem if having a discussion about such things could lead to its compromise.
However, I have no expertise in the subject so I could be wrong.
Yes, it is wrong. There's no reason to disclose the security systems of your previous employer, and there's no reason for an employer to ask. Any security question that can be asked specifically about one company, can be asked and answered in a more general way.
It's the difference between - "What security controls were in place at Corp?" and "What security controls would you put in place to protect X system?"
The 1st version is bad, not just because it discloses security controls at the previous employer.. but also because it makes the candidate responsible for (possibly bad) security decisions that were outside of their control and/or existed before they were hired.
The 2nd version gives the candidate a chance to talk generally/ideally about security.. even if the previous employer did something else.
So if my current employer uses SELinux heavily and I answer a question on how to fix an http server because of a missing or incorrect context your guy would say "Nope, you disclosed secrets, get lost?" Probably not. But if I give it as an example because I once had to do it for real I'm out? That's a very fine line to draw. I agree something specific to an employer could be an issue, but there are plenty of problems no employer may uniquely claim.
Defense in depth is stacking several flawed defenses hoping no attacker is aware of enough flaws to get through all of them. If any of the defenses were actually secure you wouldn't need the others. But we as an industry can't yet make anything secure.
High-level discussions of how you designed your architecture is fine. But once you get into details, that gives someone enough information to start to fine-tune an attack on it. The more information they get, the better they can attack it. So, yes, in an ideal situation, you would be secure even if they did know your details, but security is never perfect. So it is wise to be conservative in sharing details.
Yes, we like to have all of the secrecy condensed in secret key(s).
On the other hand, there's "defense in depth" too. Just in case we made a mistake, let's not make it any easier on the hacker then we need to.
Social hacking in particular (gaining access to employee, who has access to local network, which has access to server X, which connects to the database...) can be assisted by inside information.
That sounds like a great trick until someone doesn't see that it's just a hiring game, calls him out on it and publicly accuses him and his company of abusing interviews to socially engineer information about rival companies.
I agree that a guy looks like an idiot when he thinks there's nothing wrong with it.
That said, I doubt you will come across any fast growing startup whose early codebase was exquisite enough to put on github.
A lot of early startup codebase will be messy by nature and it't not fair to "look at a company differently" just because of that. In many cases what happens is the founders try out all kinds of things to make it work, and one day it starts working suddenly, and it works so well that they don't have time to go back and refactor anything because they have to focus on sustaining the growth.
Not saying that's how it should be, just sharing my perspective on why these things happen.
The WTF is not about the quality of code, it's that the engineer offered w/o asking the company's IP & secrets and didn't think there was anything wrong it.
It's a frightening insight into the culture of a company where that it is both possible to do that and not thought to be wrong.
Yeah I agree with what you're saying. But I was talking about this part:
> Needless to say, it definitely made me look at Yik Yak differently.
As I said, that's messed up that the guy thought that way but I don't think it's the company's fault. I can do the same for my employer what this guy did since I have access to a lot of private information, but that's my fault, not the company's fault for trusting their employee.
I suppose the op of the story is saying that the company Yik Yak IS its employees, which, especially for a small company, is pretty true. Isn't a company just === people that work for it?
I really don't know how you reach that conclusion.
This one unethical guy who doesn't even work there anymore, who's not even one of the founders, makes unethical decisions. And suddenly the entire company he used to work for--which really did nothing wrong and has nothing to do with this guy's behavior--is unethical?
An ex-engineer from Yik Yak reached out while we were hiring a while back.
They proceeded to supply a .zip file of their entire source code repository (yes, all of it). They said it was outdated now so it seemed okay in their eyes.
This included all of the dot files for configuration: keys, passwords, email addresses, Amazon instances where databases were at, and more.
I didn't ask for this .zip file, I was simply looking for some examples of experience.
Needless to say, it definitely made me look at Yik Yak differently.