At Blind, a security lapse revealed private complaints from tech employees
techcrunch.com
techcrunch.com
Blind could have been an opportunity for them to get direct and honest insight into how the sausage is made but instead is trolling and leetcode-your-way-to-fang obsessing.
Probably? I mean, if your hiring process is leetcode hazing by these same people, then it is self fulfilling.
That depends on the interview, isn’t it? In my on-site with one of the companies, I was asked hard algorithm questions in four out of five rounds, and then one system design round. I doubt anything related to personality would show up
Why? These companies are like Wall Street, they pay the most, so they attract people who are predominantly interested in money. These kind of people tend not to be the most upstanding.
It's also very useful, if accurate.
At least according to Blind.
Later on, I found unsavory relationship advisement going on, and further than that, outright racism against Indians in particular. None of these comments were downvoted, many encouraged and agreed upon. (EDIT: Not downvoted, criticized, sorry.(
Blind doesn't have downvotes (which could be part of the problem there).
Racism is not illegal and should not be suppressed. It does should also not be encouraged, however.
At the end of he day, people do not have the right to feel good.
> My first look at Blind rated cities to work in by how hot/available women were there (e.g. comments like "SF sucks, you have to settle on dating uglies" or "NYC women are so much hotter than SV women, no contest where to live").
It may be off topic the original post, but is most definitely relevant to the users. Nothing wrong with rating women. People do it all the time. It's about time it is made less taboo.
In the current context of rampant sexual discrimination, there is everything wrong with "rating women". To be very clear, when "rating women" I presume you are talking about the snap judgements made based on stereotypical beauty attributes relating to physical appearance.
The problem with "rating women" in this way is that ranking people according to a very small set of "desirable" attributes neglects or diminishes other very important aspects of what makes a person worth knowing and loving. Appearance becomes a top priority over and against other perhaps more important attributes including loyalty, kindness, and intelligence.
Additionally, "rating women" along such lines reinforces the sense that people are fungible sources of (aesthetic) value rather than worthy individuals in their own right. None of this even touches upon the social and psychological problems that result when people are judged on such a small set of shallow traits.
While people do judge each other based on appearance all the time, such tendencies are to be resisted and questioned because, for one, the standards of physical beauty are well-known to be shaped by the imperatives of advertising which have established that making people feel insecure drives sales.
In fact, it's not taboo to judge people on appearance at all. "Rating women" is a social norm. Not judging women based upon on their appearance is actually the rare exception.
EDIT: add preposition; remove duplicate word; delete extraneous space.
That's not just a problem with "rating women", or even with rating men (which happens a lot more than most people would be comfortable admitting!) for that matter. It's a basic failure mode in human psychology https://en.wikipedia.org/wiki/Halo_effect
And yes, marketing and advertising exploit this too. Associating a product with conventionally-attractive people is one way of manipulating us to make us feel better about it.
Sure I'd rather keep most of HN clean of vitriol, but a thread about it? We need to challenge, understand, and dissect these perspectives, not disregard them.
Oh, and on the topic of security, one guy found a SQL injection exploit and demonstrated it by giving any users who commented on their post 100 likes...
People just trusted it?
I get that to seem legitimate the users have to be confirmed in some way, but as a user... now way am I exposing myself that way.
Major things wrong: unencrypted email addresses + private messages, leaving the database without a password, database wasn't fixed until a week after knowing of the error.
I find it concerning that this kind of news seems normal now.
I understand taking their work email is asking for more info than desired. Probably they can use something zero-knowledge (I am not well aware of the concept) where someone proves their employer's identity without their own.
And I assume the company email is used to send you a verification email, which means your employer is now tipped off to the fact that you're using a site to anonymously criticize them.
Easy as this: http://ivan.dretvic.com/2011/05/remove-specific-email-from-a...
The article says "remove" but before you remove, you need to list all employees that have that email - if you just make a test account or look for the domain then you can pipe the results to a text file and that's your list of company insiders who are on the platform.
What leadership does with that info, is well, never good.
The WiFi bit doesn't matter much assuming Blind uses SSL (though I've never checked). Your company could see that you've connected but not what you've posted or read.
If you're using a company-controlled device, you should of course assume they can see all of your network activity. They could easily be capturing all of your activity on the device itself without any MITM attack.
My company knows everyone that got a link (everyone) but not who clicked the link.
!!!
!!!!!!
From the "Cryptographic Right Answers" [https://latacora.micro.blog/2018/04/03/cryptographic-right-a...]:
> Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2.
> Avoid: SHA-3, naked SHA-2, SHA-1, MD5.
SHA2 is a decent cryptographic hashing algorithm, that is true. But a cryptographic hashing algorithm isn't what you want when storing passwords, at least, not on its own.
Some of the problems with just using a hash algorithm: same passwords have the same hash; hash algos are typically fast, so brute forcing can make many attempts quickly, and they can be pre-computed into rainbow tables. There are ways to fix this (salts, work factors), but generally you shouldn't "do it yourself."; functions like those named in the quote from Cryptographic Right Answers put all that together in a nice package. scrypt, I believe, even uses SHA-2 in its construction, but also solves the aforementioned problems.
The "Purpose and operation" part of the Wikipedia article for PBKDF2 (also mentioned above) goes into some of this, as well (even if it is only recommended as a last resort, I think this paragraph is educational w.r.t. the problems around passwords): https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation
His lib is can be dropped in to any project (that doesn't have something similar built in already) https://github.com/iamcal/lib_bcrypt
Anyone writing code has no excuse for not using this, it's not rocket surgery.
SHA2 is very fast.
;)
> The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried.
That's not how hash functions work...
> Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are managing data. We use more advanced methods like salted hash and SHA2 on securing users’ data in our database.”
This sounds much more likely.
> (Logging in with an email address and unscrambled password would be unlawful, therefore we cannot verify this claim.)
So, they directly claim that weakly hashed passwords were available (and unscramble-able, apparently??), but they're unable to prove this and they're ignoring the company's reasonable explanation. Great reporting.
So, they store your data securely, but that doesn’t matter, since they also stored it insecurely, and leaked the latter.
The fact the reporter actually went the extra step to crack some of the hashes is impressive reporting actually.
I forgot my password once, but I knew the general letters and it brute forced in a minute.
If I'm writing docs for MD5, that's one thing. General tech reporting? "Unscramble" is understandable to someone who's never had to implement a password hash, which is most of the populace.
Kind of. A hash function just provides a near random set of characters of fixed length for a given set of input in a way where the output characters are reproducible for the given input. Passwords are not stored. It is the computed hash value that is stored. When a user attempts to login with a username and password the password is hashed and compared to the stored hash.
That said you don't need the actual password to login. Any input that hashes to the same hash string is acceptable, which is called a hash collision. When they say cracking the hash this is likely what they mean, and its trivial to compute provided a rainbow table.
Salting provides an additional round of computation. For example let's say a user is trying to login. Their password is hashed but before the hashed are compared some additional information is added on the end of the computed hash and that new value is hashed. It is this new hash that is compared with the stored hash, which requires knowledge of the hash algorithm, the salt, and the hash value. You can generally guess the final hash algorithm in question by observing the character length of the stored hashes, but since there are two hash computations a different hash algorithm could be used for the first round of hashing.
To be secure the salt must be stored in a different location from the stored hashes and the salt value should not be statically visible in the source code provided a source code compromise. Statically expressed passwords are uploaded to code repositories all the time. Don't believe that you are protected from associated vulnerabilities merely because the code base isn't open source.
To the article's defense neither claim was verified, but both claims were reported. When the journalist cannot validate a claim themselves, or with experts, it is completely acceptable to report the claim and report the validation status.
And for what it's worth:
> To be secure the salt must be stored in a different location from the stored hashes and the salt value should not be statically visible in the source code provided a source code compromise.
This isn't true. Your salt can be totally public if you're using a robust key derivation function. Likewise you can make e.g. the work factor (rounds) public for bcrypt and N, r and p public for scrypt (cost factor, block size and parallelization parameters).
The rest of what you said about secrets management in code is sound though.
> Your salt can be totally public if you're using a robust key derivation function.
That is a deliberate strawman. If your salt is based on keys there is still information you aren't exposing even if you are exposing the salt itself.
And your second paragraph doesn't follow. What I said isn't a strawman attack, it's a basic observation. If you're not using a secure key derivation function, a private salt will not save you. If you are, the salt can be public and there is no meaningful degradation in security whatsoever - you could even prepend or append it to the digest if you'd like.
As a broader point, what you're saying about fixed-length strings is incorrect. Hash functions need not output strings of fixed length. The formal definition of a hash function also admits functions of the form:
H: {0, 1}^* -> {0, 1}^*
H: {0, 1}^* -> {0, 1}^n.
The reporter says they successfully produced passwords, sounds clean-cut and dry to me.
Don't you think this is a pretty important claim to verify, instead of asserting without giving proof? Granted, if a dictionary attack gives you a bunch of 'password' variants, you probably don't need much more evidence.
If the reporter is so invested in producing this story, then being able to say "no, these are definitely passwords" in the face of the executive would be the golden ticket, right?
This is outdated though. You don't need to take extra steps to secure the salt if you move to a good hash.
You either haven't found the interesting threads or the interesting replies from internal people that make Blind different.
People are welcome to enjoy whatever fiction they want to read. I'm just saying you'll probably find more useful and reliable information elsewhere.
Wow a patented infrastructure! Dope!
I wonder if it's open source so that can be validated objectively?
"Patented infrastructure"? It smells like BS to me.
Reason enough not to work there if you ask me.
There is widespread available technology and know-how on how to do this successfully and consistently.
Blind failed miserably at this fundamental task.
Yet... >>Blind last month secured another $10 million in new funding after a $6 million raise in 2017
So the VCs are perfectly happy to dump millions into a company that is dishonest and incompetent (see also Uber, Theranos), while thousands of competent honest startups go begging.
Provides a bit of background into why most VC funds struggle to outperform the market
There is less moderation on Blind, so there are more "provocative posts" that people definitely do not want associated with an identifier.
Also, the community there is pretty toxic. I understand it's mostly the design of the app to be a place where people can say what they want, but I think it attracts a certain type that I'm not terribly interested in getting close with.
> Email verification is safe, as our patented infrastructure is set up so that all user account and activity information is completely disconnected from the email verification process.
https://patents.google.com/patent/US9439072B2/en?oq=9%2c439%...
> Certain embodiments herein also provides a system and method for authentication, which can prevent service users' identities from being exposed even by hacking of a terminal or server side of a service provider, negligence in information management or a manager's misconduct.
impossible.
> Certain embodiments herein also provides a system and method for authentication, which can store information provided by a service user during subscription and authentication procedures in such a manner that the information cannot be decoded from a side of a service provider's server.
Impossible without a trusted 3rd party to perform the authentication and return a token to the service provider. Which is a well known and well deployed, not novel technique.
Patents are hard to read, and this one is no exception. Unfortunately I don't have enough interest to invest the time required, but at a glance it seems that the technique is to have an authentication server that can hide the user identity from the relying service, basically by replacing it with a token. Too obvious.
But there's some kind of dedup exchange mentioned; it might be that the auth server doesn't itself store a list of the identities that it has authenticated previously so it has to interact with the service (in a blind way) to dedup. Perhaps the novelty here is that the service itself cannot uniquely identify users; ie each post could be coming from any user in a group. All the service knows is that the post is from a user in that group. On its face, that seems false -- for the first time ever I actually looked at blind and each post has a user pseudonym as metadata. There would be no point to that pseudonym if it didn't represent a uniquely identified individual user.
Anyway, all this is meaningless protection unless there is adequate SoD between the auth server and the service provider, which for teamblind it is obvious there is not.
</conspiracy>
Heh, guess I could just use this table of hashed passwords that they exposed and figure it out myself ;-)
wanted to add, with all the recent (and we know to be continuously ongoing) talk about chinese espionage ... who needs high-cost espionage when you can get employees to air dirty laundry at zero-cost?