He never 'got a lawsuit.' Instead, he got some comments from the contact to whom he reported it that criticized his approach. It's not even clear just who this person was. It seems he had trouble locating a contact to report security issues to, so this may as well have just been a low level support rep who was in over his head and saying things he shouldn't have.
"The hardest part - responsible disclosure. Support guy honestly answered there’s absolutely no way to get in touch with technical department and he’s sorry I feel this way. Emailing [email protected] on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.
> So far as I know (this is sort of my profession), there's no federal "burglars tools" law regarding malware.
To be fair, many "burglars tools" laws require possession of the tools WITH INTENT to perform a criminal action. The intent piece is key. Merely possessing lock picks is usually fine. But sulking around masked in bushes outside an office building with a pickset, rope, and an empty duffel bag might get you in trouble.
A good list of Lockpick laws collected and indexed state-by-state at http://toool.us/laws.html. You see that in most jurisdictions intent is required.
While malware laws are still much less mature, I would hope that similarly there'd be an intent requirement. Possessing malware for purposes of reverse engineering to develop protections is obviously important, and clearly an activity we would want to remain lawful (and hopefully unlicensed/regulated).
Conspiracy is probably the easier route to a conviction.
In the comments, they indicate that they're in the process of sending out emails to users. Sending lots of emails takes some amount of time; hopefully those are arriving in inboxes now.
It's low key given the impacts as they understand them now, but seems reasonable unless there's more to it than it currently known. We'll see how things develop in the coming days - just being forthcoming days after it was detected and providing guidance on how to respond is commendable though.
This is one of the things that scares me. If an attacker had access to dump their credential digests, could they also have modified the site to silently log credentials upon entry?
From their statements so far, it doesn't seem that happened, but it seems likely that it could.
People may laugh, but for many people that's a huge step up. I've tried explaining password managers to family members, and I've failed. The usability just isn't there for many classes of user, and as noted elsewhere in this thread losing access to that database is catastrophic.
Getting them to use unique passwords per-site, even if those passwords are written down and stored in their desk drawer, can be an improvement.
I'm far less worried about someone breaking into my (grand)?parent's house and stealing their password diary then compromises their bank account than I am someone popping some random site and re-using the compromised password.
Now for enterprise credentials where the (physically) stored credential and the service to which it's applicable have a closer proximity there's a higher change of this kind of meatspace targeting. But then, the 'common local admin password across all domain-joined machines' problem persists too.
I would also appreciate more detail, but that shouldn't be their first priority.
They note that they discovered the breach on 'Friday' so I imagine they have an ongoing Incident Response right now. They may not have or be ready to share this information at this time, and that's fine. They might be working with law enforcement, further hardening systems, and continuing to confirm their findings to date to ensure they've mitigated the full impacts.
What's important now is conveying how users are impacted and what steps they should take to protect themselves; hopefully the rest comes in time.
> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.
Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.
I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.
For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.
> So the choice once more, for me, becomes cloud-based password manager or no password manager at all.
If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.
> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.
I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.
While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk.
If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one.
Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which you have no control seems inherently risky. Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database. Use a password manager, please, but keep it offline and don't aggregate it with loads of other people's databases.
This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.
Long-time Hacker News readers will be familiar with Matasano Security, and will expect to see us post in this thread. This month, there will not be a post from Matasano Security. Effective today, there will no longer be a Matasano Security. Instead, we're officially rebranding as NCC Group.
In late 2012, Matasano was acquired by NCC Group joining iSEC Partners and later Intrepidus Group. Since that time, we've been working together, cross staffing projects and benefiting from each other’s expertise. It's been a slow, steady process of increasing cohesion. We've reached the point where we need to assume a single identity, that of NCC Group.
Being a part of this process as it unfolds reminds me a bit of watching the Voltron cartoon series as a child in the '80s. The show featured pilots each commanding their own robot lions. Robot lions are fierce, powerful beings. But when they came together they'd form Voltron - a giant humanoid robot with the lions compromising each of it's parts. I like to think this is what's happening at NCC Group. What were previously separate companies each well accomplished in computer security are becoming a single even more formidable entity. "Form arms and body! And, I'll form the head!"
So, what does this have to do with hiring?
Growing a larger company requires a larger number of individuals. We still need candidates with the same skills as always; programming, reverse engineering, protocol analysis, web application building/breaking, adversarial thinking. We need people who understand technology and can identify flaws in how it's implemented. We need those who can look at a security weakness, and accurately gauge it's relative risk to the organization. And we need folks who can communicate that risk to multiple audiences, in varying levels of detail.
There's no better time than now to join us. Our integration effort has opened up opportunity within the company to focus on areas of specialization, advance skills, and take on ever more complex projects and challenges. If you've always wanted to be part of something new, but found yourself averse to the risk of early stage start ups, joining us now might be a way to do both. We're stable but we're evolving and changing, and our employees will shape what we become.
Please, bear with us on the sites above. We've migrated a boatload of content, and it's likely there will be some website wrinkles. We'll iron them out as soon as we can (mostly we'll just keep breaking interesting software).
> Any interview process that requires a substantial time investment by the candidate pre-interview is broken.
I disagree, but accept that this depends largely on the desired outcomes. If the candidates goal is to spray-and-pray by applying at dozens of companies and hoping one makes them an offer they can accept, I'll grant that requiring more time may be a hindrance. If, however, the candidate's goal is to learn something, improve their skills, and demonstrate to the potential employer that they're capable of doing this on a short time cycle, they may welcome the opportunity, and many have.
> Why would I spend some time learning the security niche just for one interview? I could instead work on Android development, Python, Scala, or a whole bunch of other things. Those would be useful for many jobs, and not just 1-3 employers.
Because you want to work in security generally, and for us specifically? I fully accept that not everyone shares career goals which align with our needs, and encourage them to pursue other avenues. If you're dream in life is to be a broadway actor, we're unlikely to be able to help. That doesn't make this goal less important to you or valuable to the world at large, it just differs from what we do and offer.
That said, if you think that security skills (and web app security specifically, which is the typical path for those learning for the interview) are relevant only to "1-3 employers" I fear you drastically underestimate the size of the market both within security consultancies and enterprises that have a security team (or just appreciate security-minded developers).
> Why is putting in a lot of time researching security for your interview a better use of my time than learning more widely applicable skills?
It may not be. There's a lot of paths to self improvement, and their suitability to a specific individual will vary, depending on that individuals goals, desires, and learning style. I don't think anyone is trying to prescribe 'the one true path to self improvement' but rather one that we've found to work, and one that we help our candidates advanced down.
> What if I put in all the time, pass the pre-screening, and then when I meet you, it turns out you aren't the type of people I'd want to work with?
Then we shake hands and each go our own ways, hopefully having learned something about each other and ourselves in the process. Maybe we've made contacts that'll be mutually valuable in the future whether it be for future employment, a business relationship, or simply someone to chat with at some developer meetup, conference, etc. and bounce ideas off of. Choosing not to continue a relationship is a perfectly viable outcome of any interview process.
The security of computer systems has increasingly become an everyday concern. The news all too often brings word of yet another compromise, exposing financial information, personal details, or simply salacious pictures. Whatever the impact, it's clear the technology industry has a problem, and there are few easy solutions.
Some seek legislation to impose harsher penalties on the responsible parties. This ignores the fact that many of those responsible are outside the jurisdictions which seek to punish them. In some cases, they may have tacit approval of their own government, or even be operating on their government's behalf. Others turn to established security products looking for antivirus and network filtering technologies to add protection. This is an also an imperfect solution. It places the defender in a reactive posture, responding only to those threats which have been previously detected, and for which countermeasures have been developed. There's no perfect solutions.
At Matasano, we believe the best way to combat security weaknesses is at their source; by discovering and remediating software vulnerabilities before others leverage them for ill effect. Our clients see the value in this approach. We're engaged to work on some of the most interesting and important software on the planet. Aside from identifying vulnerabilities, we help our clients identify the root cause. Through this, they can adjust processes to reduce the likelihood of similar problems in the future, while increasing their ability to identify and correct them. The goal is more resilient software.
We've assessed hot startup web applications, low level device firmware, mobile platforms, and everything in between. With this breadth, we have need for employees skilled in frameworks like Node, Rails, Django, and Spring. We need people comfortable with x86 and ARM assembly, reverse engineering, and binary protocol analysis. If you're skilled in a programming language with the letter 'C' in it, that's desirable. Newer safer languages like Rust and Golang are in demand. In short if you share our focus on helping secure our software ecosystem one piece at a time and want a chance to do something about it, we should talk.
Next month, you'll notice a change in these posts. Since being acquired by NCC Group in 2012, Matasano has been working increasingly closely with our peers at iSEC Partners and Intrepidus Group. The time has come to formalize this, by adopting a common name; next month I'll be posting under that name.
Yes, it likely will. That's probably why the article mentions a deprecation of "Non-Secure HTTP" rather than prescribing a specific TLS version. It's the sort of language that will stand the test of time as newer protocols become deprecated. The comments here, however, largely encourage "SSL" which is poor advice.
BEAST can be mitigated through ciphersuite selections and other measures. This makes it somewhat different than POODLE which is a protocol design flaw for which no reliable mitigation exists.
Suggesting folks not deploy SSLv3 is hardly a controversial statement. It's not just a difference in version number, it's a difference in protocol specification and name. When we say 'Use SSL' a well intentioned reader may follow that guidance and implement SSLv3, or worse disable support for TLS. Words mean things.
The differences are significant when it comes to the security of the underlying protocol, and the downgrade is why it's important you refuse to support SSL entirely. SSL of any version (v2 or v3.. the v1 you refer to was never publicly in use) comes with security problems that are resolved in TLS.
I won't bore you with the details, they're well explained at http://disablessl3.com/ among other places. All major browsers have ended support for SSL, and more secure alternatives have been available for years.
It's not a high risk; attacks require scenarios that may not be common, but it remains true that there's no reason to deploy SSL today.
SSL means something very specific; something that people should no longer be deploying. The article notably uses the term 'Non-secure HTTP' which at this point in time means HTTPS leveraging TLS (probably at least 1.2) but leaves some room for future interpretation as newer versions or entirely different standards arise.
No one is advocating for 'SSL' here, and continuing to use the term 'SSL' or 'SSL/TLS' when we really mean 'TLS' further confuses the situation.