275 karma · joined November 6, 2013
We're currently making the final decisions regarding summer internships. When we're accepting applications for intern candidates again, I'll be sure to note it accordingly in hiring thread posts at that time.
Sure. This is something I touched on very briefly near the end of the post. Password re-use is a huge problem and could easily be an blogpost of its own.
> On the other hand strong passwords will withstand an attack even if they are hashed with plain MD5 or SHA1 - at least right now, there are already some serious collision attacks.
For some value of 'strong' sure. If you're password is long enough, random enough, and of a broad character set then yes, an md5() of that may well be beyond the reach of most attackers. But that's not the sort of password most people, even security conscious people, choose. A preimage against MD5 would quickly change this too, and that's a risky gamble.
> The user group really benefiting from strong password hashing schemes is the one between the two mentioned extremes.
The best we can do is make attacker costs a function of the password that the user has chosen. If someone makes their password 'password' there's no degree of magic that's going to help. Mostly, the benefit comes if/when disclosure occurs and there's an active incident response effort.
> So if you really want to protect all your users and use simple password authentication you have to enforce strong passwords policies which is itself not trivial and will definitely badly annoy some users.
It's not a zero sum game. When a breach occurs, the rough points in time are something like:
1) Attacker compromises digests (let's just assume all are obtained in an instant, rather than exfiltrated over time) 2) Attacker recovers 1 password 3) Attacker recovers n passwords 4) Attacker recovers all passwords
Our goal isn't to eliminate these steps except hopefully the extreme of 4. Rather, it's to increase the time between 2 and 4, and make sure 3 is closer to 2 than 4.
On the other side of the coin, there's a few points in time:
a) Victim org. realizes digests have been compromised. b) Some credentials valid at 1 are made invalid. c) All credentials valid at 1 are made invalid.
If you accept my previous point that at some extreme there's nothing that can be done to prevent brute force, then you should also see that storing passwords in this fashion isn't meant to be a perfect defense. By minimizing the number of compromised accounts at a given point in time, we can maximize the benefits of our response. We can notify users and force resets, invalidating some set of credentials before they're recovered. We want b and c to be closer in time to 2 than 4, and minimize the value of n when we get there.
I can probably count on one hand the number of times I've seen an application use bcrypt or scrypt and define their work factors. The common case seems to be sticking to the defaults that their chosen library ships with. While these may be somewhat less than ideal, it's universally true that these schemes are stronger than salted passwords fed to a fast cryptographic hash.
MATASANO SECURITY - Chicago. New York City. Sunnyvale.
Application Security Consultant
Full-Time, work visa sponsorship available
~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~
What excites you and ignites your muse?
When I was a child I'd often get in trouble for 'breaking' things. Teachers, parents, and other authority figures didn't understand what motivated this behavior, but with the benefit of hindsight I now do. I wasn't breaking things at all, I was exploring them. I was learning how they worked by taking them apart and seeing them laid bare. Sometimes, I'd manage to put them back together and occasionally they'd even work!
Once, when I was about twelve or thirteen, I took apart a mechanical bedside alarm clock, laid all the gears out organized by size and was promptly grounded for 'destroying' it. While serving my punishment, I went to work re-assembling it, with one small change. What had previously been a cheap cardboard clock face was replaced with a piece of translucent contact-paper, with numbers careful stenciled in their proper places. I loved that clock. Every morning I'd wake up, see it, and glance deep into its inner workings. That visual reminder that I'd been curious and unlocked its secrets was how I started mornings throughout my formative years.
Somewhere along the line, I lost track of where that clock ended up. It may be gone, but the spirit it demonstrates remains one of my strongest motivators. I've found no better outlet for this drive to understand the inner workings of things than software security assessment.
At Matasano, we treat our client's applications like I did that clock. We take them apart, examine them piece by piece, and arrive at an understanding of what makes them tick. Only after arriving at this can we find and exploit vulnerabilities. We slap a clear face on those applications, with the numbers carefully identifying any discovered flaws. We take them apart and 'break' them, not to be destructive, but to be constructive through understanding them. Thankfully, we don't even end up grounded. :)
There's no area of computing that draws on as many skills, but programming, debugging, protocol analysis, reverse engineering, systems administration, network engineering and cryptographic analysis aren't what make great AppSec consultants. You need to find what motivates you. For me, being tasked with quickly developing a deep understanding of unfamiliar applications plays right into the mindset that led me to explore that clock.
So, again I'll ask, what excites you?
Learn about our hiring process at http://www.matasano.com/careers or contact us at careers@matasano.com
Get a taste for some of what we do at http://www.microcorruption.com and http://www.cryptopals.com
Check out our blog at http://chargen.matasano.com
~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~
Yah, that does seem like a reasonable design. The implementation wrinkles there are that the hardness params have to be encoded in the digest itself, or otherwise stored alongside it. Since implementations commonly do this anyhow, that doesn't seem likely to pose much problem in practice (if any). The other issues would be details around when to calculate the hardness. On app initialization seems obvious, but you'd have to sample over some period of time to get a representative benchmark. I worry that this could exceed administrator tolerance for how long an app can reasonably take to start up, but this doesn't seem like a show stopper either.
Ultimately though, I'm not sure the factors are THAT variable. I mean, you want to reconsider work factors as hardware advances, but I don't think the line is so solid that running a work factor of N versus N+1 will make that much of a practical difference in the span of a few months or even a few years. Still, with the goal of making it as hard as feasible while still being suitably performant in the context of a given system it makes sense.
"Each of these algorithms requires setting of an appropriate work factor. This should be tuned to make digest computation as difficult as possible while still performing responsively enough for the application. For concurrent user logins, you may need <0.5ms response times on whatever hardware is performing the validation. For something like single user disk or file encryption, a few seconds might be fine. As a result, the specific work factor values appropriate for your application are dependent on the hardware running your application and the use case of the application itself. Thomas Pornin gave some great guidance on determining these values in a post to stackexchange"
The stackexchange post (which is linked in the article) can be found at http://security.stackexchange.com/questions/3959/recommended...
One such example (from 2007) was ported over to our relaunched blog. http://chargen.matasano.com/chargen/2007/7/27/this-new-vulne...
Of course, this gave rise to the ability to transfer files (even non-public files) quickly between Dropbox accounts provided knowledge of the hashes of its chunks, and Dropbox has since changed their deduplication. See https://github.com/driverdan/dropship
MATASANO SECURITY - Chicago. New York City. Sunnyvale.
Application Security Consultant
Full-Time or Internship, work visa sponsorship available
..............*________________________________________________________
<Mission Impossible theme plays>
What made the original show so great is exactly what was lost in the 'Tom Cruise takes on the world' reboot. The original 1960's and 70's Mission Impossible was defined primarily by a team working together against all odds to achieve their objective. It acknowledged that what they were doing was improbable, and more so for a solo James Bond or Tom Cruise character. As a team though, each character an expert in their particular focus area, the incredible became credible -- the impossible, possible.
Working at Matasano is a bit like working for the Impossible Missions Force (IMF). No, we're not taking out thinly veiled cold war era Soviet stand in villains, preventing the rise of the third reich, or being tasked with gathering evidence against criminals "outside the reach of conventional law enforcement." But in many cases, we're given tight timelines and tasked with difficult objectives. To the uninitiated, what we do is often seen as impossible, but _together_ we do it every day.
Imagine you (and your team) have a month to circumvent a real world cryptographic system designed and sold for Fortune 500 companies to protect their most sensitive intellectual property. Maybe you're given a week to investigate and undercover flaws in a brand new Ruby on Rails application. You might find yourself facing a never-before-seen client/server application, implementing a proprietary binary protocol, and having to figure it out and attack it. You could end up drawing on binary reverse engineer skills, or reviewing Java code. But whatever the 'mission', you won't be alone. You'll be part of a team of experts, each bringing their own skill set to the team.
We don't have very much call for demolitions experts, special effects makeup artists, or champion weightlifters. Like the IMF, we're looking for people with diverse backgrounds who each bring something unique to the team. There's little in computing that isn't useful for an Application Security Consultant. We need Reverse Engineers. Developers of all backgrounds, Cryptographers, Electrical Engineers, you name it. We're as likely to hire a Mathematics PHD as a college drop out. Many of our best employees have little formal information technology background. In short, we come from a variety of backgrounds, but share one common trait -- We're curious about nearly everything, and have a wide base of knowledge, but have achieved mastery over one (or more) disciplines. These are the sorts of people the IMF built their team from, and they're the sort of people who we're looking for at Matasano.
Your mission, should you choose to accept it, is to visit www.matasano.com/careers to learn more and contact us. In the enclosed dossier, you'll find links to www.cryptopals.com and www.microcorruption.com which may be of interest. Further intelligence is available at the chargen.matasano.com blog, and you can always contact careers@matasano.com with any remaining questions. As always, should any member of your team be caught or killed, the Secretary will disavow all knowledge of your actions.
This isn't Mission Difficult, it's Mission Impossible. Difficult should be a walk in the park for you.
This tape will self destruct in five seconds. Good luck.
________________________________________________________________--(BOOM)
In the Lenovo case, probably not. But in the case of an employer-provided system and network intended for business purposes which performs SSL interception for security and data leak prevention? I think it can clearly be considered reasonable for the company to do that, and the user's expectation of privacy is significantly different. I do feel it's important that Acceptable Use Policies, Employee handbooks, etc. disclose the activity though.
Your view seems to reflect a similar nuance as my own. Administrators need to weigh the risks and benefits as it relates to their own environment, and users should at least be aware that such monitoring is taking place. Beyond that, there's some technical challenges, but I see the bigger issues as political and expectation vs. reality alignment.
There's also a video of my talk online, which I'd honestly forgotten about. Maybe someone will find it interesting; https://www.youtube.com/watch?v=7TNdHzwTNdM
I presented on the topic at Blackhat Europe a few years back, where I disclosed several certificate validation flaws in Cisco Ironport. I understand there's legitimate reasons for enterprises to want to decrypt and inspect TLS connections, but it's not without it's risks and downsides.
If you're curious about my past work, see: http://www.secureworks.com/cyber-threat-intelligence/threats... http://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-SS...
Compare that savings with the additional size of URL parameters (increasing network overhead) in addition to the processing overhead of encryption/signing/validation. Have we really made a performance gain? I don't have any hard numbers, but I'm willing to wager than at gains are fairly negligable.
From a security standpoint, I'm not fond of this approach, and I don't think it's benefits outweight the added risks. Here's why:
- Encryption (including simple signing) is really easy to get wrong in subtle ways. A simple mistake like using SHA256() instead of HMACSHA256() breaks the system badly.
- A corralary to the first point is that using a strong key is vital. The article says nothing of the criteria a strong key should meet and a poor key could enable additional attacks. While I'm not aware of anything allowing for HMAC key recovery in better than brute force, this could be problematic. If your key is a random 10 character ASCII string, it falls to brute force in minutes at most. If it's 256 random, you're much better off.
- This scheme introduces a significant number of anonymous user-supplied inputs to the application which didn't previously exist. Each of these is a potential place for things to go wrong, which can give rise to other vulnerabilities (XSS, SQLi, etc) depending on what you're doing with that input. You'll need to be sure that you validate the signature prior to doing anything with these unverified inputs, in addition to performing sanity checks on their contents prior to signing. Part of secure application design is to minimize attack surface and complexity - this does the opposite.
- Once a signature is created, it can't be revoked. I mean, you could store the signature in the database and validate it's presence on receipt, or include in your signed values a nonce that's stored in the database, but that kind of defeats the goal of avoiding database storage. This is something the article tries to address by signing over things like an expiry time, the user's old password digest, etc. But that's insufficent as well (I'll get into why below).
- While I'm not aware of anything allowing for HMAC key recovery in better than brute force, choosing a secure key is still important. The article says nothing of the criteria a strong key should meet and a poor key could enable additional attacks.
- Even if you get everything right, key exposure is fatal. You've introduced a single point of failure in the system that didn't previously exist, and a fairly catostrophic one. If the app ever leaks that key, you're only option is to rotate it (assuming you detect the exposure), which invalidates any existing signed values.
That's the broad points, let's look at the article's examples:
http://myapp.com/resetPassword?userId=johnnysmith&expirationTime=1356156000&token=%SECURITYHASH%
As the article notes the token can also be reused multiple times, even if johnny has already used it. They offer a means of fixing this:
HMAC256("userId=johnnysmith&expirationTime=1356156000&oldBcryptHash=$oldBcryptHash&clientIpAddress=$clientIpAddress", $mySuperSecretKey)
Furthermore, this token is still valid if Johnny requests a password reset, and while waiting for the email to arrive remembers that he changed it from 'Password123' to 'Password456' and logs in. There's then a window of time where that token remains valid (until expirationTime arrives) and can be abused. The article doesn't address this case at all. I suppose they'd say that on issuing a token, you should disable login to Johnny's account until he's reset, but how would you do this? Well, you'd set a flag in that database on Johnny's record, and we're kind of back where we started again with both a database read and write, but with added cryptographic overhead and attack surface too.
The next example talks about account registration. It states that you can verify a user's email account by sending them a link to:
http://myapp.com/createAccount?email=johnnysmith@gmail.com&token=%SECURITYHASH%
Case Study 3 talks about one-time-use and expiring resources. There's not enough detail here about their scheme for me to really critique, but they point out AWS/S3 use of HMAC signing as an example. Except that AWS/S3 signing isn't about one-time use or expiration. Instead, it's about authenticity.
AWS operates with an ACCESS_KEY and SECRET_KEY which are a pair of tokens related to each other. Requests with 'params' are signed as:
Signature = HMAC(ACCESS_KEY + params, SECRET_KEY)
This can be done reasonably well, but it's a minefield to navigate when we have a tried and true solution. What's so bad about database storage of tokens? The post kind of starts with the assertion that they should be avoided, but I see no clear explanation as to why.
I read their text as recommending A or B, based on the intro where they state "Two approaches facilitate this, each imperfectly."
"As even if you utilize separate device (HSM for example) for encrypting the passwords (I'd encrypt instead HMAC), you should indeed not give up on adaptive hashing."
Right, this is the sort of thing that led me to hedge by saying I MIGHT be convinced if an HMAC were involved; it still gives me pause, for sure.
Specifically, it suggests storing passwords using: `return [salt] + HMAC-SHA-256([key], [salt] + [credential]);`
It goes on to note that the key must be protected as private, strongly random, and stored outside the credential store, while the salt (can we please call it a nonce?) can be safely stored against credentials.
I'm still not comfortable with this construction. Stick with their earlier advice and use scrypt, bcrypt, or PBKDF2. That's my order of preference too, which differs from theirs somewhat, but that's a minor quibble; all three are reasonable.
The problem with their construction is that HMAC-SHA-256() is designed to be fast, and so attackers have the opportunity to make a lot of guesses quickly. The secrecy of the key helps over a straight SH256(...), but not a lot for the following reasons:
1 - It assumes an attacker who compromises the credential store won't also have the key.
2 - It assumes an attacker is unable to recover the key.
1) is a valid assumption for certain classes of attack. If your key is stored in an environment variable or something, while credentials are stored in a database, an attacker who compromises your database via a SQL injection won't have the key. But the problem is that an attacker who compromises the application may. If I have full remote code execution on the server (and you have a bad day then, passwords aside) I'll have the key. Or maybe an attacker has an arbitrary file read (not quite as bad a day), and you store your key in a flat file on disk. Or an attacker can cause your application to generate a stack trace (disclosing runtime details) and view the key...
You get the idea - there's lots of potential ways to get that key regardless how you store it, and everything hinges on that. Once they have the key, they can mount dictionary or brute force attacks against credentials just as they would against `SHA256([salt]+[credential])`
2) is a valid assumption only if the attacker doesn't know a single password's plaintext value and the key is sufficiently long and random. If I know the password to my own account (and I likely do) or any other account (let's say one user on the site uses a password that was recovered in another breach) this scheme fails.
Suppose my salt is "SALTYSALT" (okay, so my PRNG sucks; also a detail to be wary of) and my password is ye olde "PASSWORD" (yah, this sucks too.. but it's my crappy password. Maybe I added it just to observe the resulting HMAC value?) Now I can just try calculating `HMAC-SHA-256("A", "SALYTSALT" + "PASSWORD")` If that doesn't match, try `HMAC-SHA-256("B", "SALYTSALT" + "PASSWORD") and so on. The one thing I don't really know that would help is the length of the key. If it's long enough (We'd want at least 256 bits), and strongly random, I may have a difficult time. It it's short (And they make no recommendation on it's length, just that you "Generate the key using cryptographically-strong pseudo-random data"), I'm going to crack the key, and then I'm back to attacking all the other credentials.
I MIGHT be convinced of this being reasonable if it can be ensured that all the HMAC calculations are done in something like an HSA or TPM which generates a large key internally and doesn't expose it, even to the application. But that's probably not the scenario we're talking about here. Even then, you've got nothing to lose by using an adaptive algorithm rather than the HMAC construct. For anything else, it's far safer (and easier really!) to use scrypt, bcrypt, or PBKDF2. So just do that.
February - The shortest month of the year, and one of the coldest (maybe not so much in our Sunnyvale, CA location). That month every year when we set aside some time to show appreciation for our loved ones through gifts, greeting cards, dinner dates, flowers, and a well considered application security posture.
Maybe that last one isn't on everyone's minds, but it is here at Matasano Security. In many environments, while application security is desirable, it generally isn't a primary requirement. Applications need to perform their core purpose, whatever that may be, so they can aid business by driving revenue. The conflicting priorities can lead developers to make poor design decisions, rush implementations, and spend less time considering attack scenarios than would be ideal. This isn't their fault! It's a function of conflicting priorities and focusing on those which are most tangible, and most measure.
At Matasano this balance is different. Application security is our passion, and our goal is to fill the unmet needs our clients have to strengthen their posture. Our singular focus on security helps us maintain an aptitude and laser guided precision that's far above the mean. We truly enjoy combing through code, reviewing the flow of information into and out of an application, and finding places where malicious actors can leverage vulnerabilities to their advantage. We love our clients, but it's not the sort of love you'll read about on little candy hearts. We tell them the truth about their security, not just rosy platitudes.
Sometimes this can mean delivering bad news when we're able to totally compromise an application and execute our own code on its server. Other times it means explaining that when the server asks the client to identify itself, the client can just lie. Often it means explaining that their homegrown encryption scheme is no more unintelligible than Pig Latin. But with this bad news comes some assistance and guidance to help them prioritize improvements and strengthen their products.
This sort of work requires a very particular set of skills. A strong Application Security Consultant needs to deeply understand programming and application design. They require a foundation in the common application vulnerabilities, exploitation techniques, and mitigations. But more than this they need to be creative and able to maintain multiple perspectives simultaneously to find places where those perspectives are in conflict. They need to quickly learn and teach themselves, their peers, and their clients. Above all, they need to be able to communicate well and provide actionable advice to our clients.
If you want to see more about the sorts of things we do and love, here's some resources; Our blog - http://chargen.matasano.com The Matasano Crypto Challenges - http://cryptopals.com Microcorruption, Embedded Security CTF - http://microcorruption.com
If you think you have what we need, or just want to learn more about us, visit http://matasano.com/careers or contact us via careers@matasano.com.
Some of our employees hold PHDs and/or Masters degrees, others (like me) don't even have a Bachelors.
We also have a history of interiewing the same person repeatedly. I myself interviewed twice before I came to Matasano. There's nothing wrong with realizing it's not a good fit at this time, and coming back around at a later date. Seriously, you can't waste our time.
Full-Time or Internship, work visa sponsorship available.
The start of a new year is a time many people become a bit introspective and reflect on their lives and careers. Those of us who enjoy what we do, and find satisfaction in our work take account of our accomplishments and achievements in the past year. Others may be less satisfied with their current position, and resolve to improve it. If you find yourself in the latter camp, my advice is to find a job for which you are passionate, motivated, and talented. Find your muse; something which engages your heart and mind, and gives you a sense a fulfillment.
For those of us at Matasano Security, this sense of pride and accomplishment comes from assessing the security of application software. We find few things as inately satisfying as discovering ways to abuse application logic and bend it to our will. Better yet is the satisfaction that comes with knowing our clients can now use our information to secure their applications and protect their clients. It takes meticulous attention to detail, and the ability to think outside the box and consider cases the application's own developers didn't. Application Security can be both an intriguing mental puzzle, and an extreme adrenaline rush in a way few disciplines of computing are.
In the coming weeks, gyms will fill up with new members intent on exercising their bodies. Me? I'll continue soldiering on, breaking and helping fix software, exercising my heart and mind. If you'd like to join me, check out matasano.com/careers and contact us at careers@matasano.com.
As far as I know, it's not supported by any current browser (I welcome feedback to the contrary) but is included in SChannel. Given that we've only recently (arguably) gotten away from SSLv3, I don't have high hopes that it will be viable to require channel binding in the very near term.
Most of us like working in an office close to home, and don't like traveling a lot. It works for us.
All I can really say is that we have a culture of cooperation and interaction that relies, in part, on physical proximity. It may change in the future, but for now we prefer folks to be in the office where they can interact with others with less friction.
We're a lean company, so 'Services' encompasses all positions for which we're hiring.
Matasano Security - Chicago. New York City. Sunnyvale. Job Title: Application Security Consultant
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
Once a professor shared a piece of career advice with me. "Don't call yourself a coder," he said, "anyone can learn to code, but programming takes real skill." His words have stuck with me since. Coding was, in his description, the mere act of producing something a computer can interpret and act upon. Programming, however, seeks elegance and simplicity through considered design and thought that transcends the code itself. While both take skill, the goals are different and they can be thought of as distinct disciplines.
Application Security, I've come to believe, is yet another discipline with a slightly different focus. 'Coders' focus almost exclusively on iterating until they achieve a desired result. 'Programmers' might test and refine to improve performance and reduce resource consumption. But with an Application Security perspective, we instead look at unintended functionality and edge cases that give rise to problems; 'What if' scenarios involving abuse cases that weren't part of the original design. It's yet another way of looking at the same application, with a different goal and different outcome.
At Matasano, we don't build software, we break it. We find, exploit, document, and prioritize flaws so the application's developers can address them. We identify when security controls are effective, and note areas for improvement. We review use cases, identify abuse cases, and help guide future development efforts. We work across a wide variety of applications ranging from simple web apps, to complex hardware appliances. From HTTP to proprietary encrypted protocols, and everything in between. As a team, we're as comfortable with ROP chains and memory corruption vulnerabilities as Cross-Site Scripting and SQL Injection. As individuals, we excel in our areas of focus while cross-training and broadening our skills. We're among the leaders in our industry and community, and give back through research, tools, and practice environments.
If improving the state of software security while kicking up some dirt in the process seems like fun, check us out. If you're fueled by pride of finding unexpected solutions, we have plenty of challenging problems for you. If you're not content to be a 'coder' and long for something more fulfilling, get in touch.
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
careers@matasano.com or www.matasano.com for more info
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
Curious about Crypto? - www.cryptopals.com Mesmerized by Memory Corruption? - www.microcorruption.com
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Trying to sort out an appropriate security contact, especially for relatively minor vulns like this (though it's likely also reflected cross site scripting on benefits.gov) is a nightmare.
Another example involves some work I did while at a previous employer: https://web.archive.org/web/20131114050720/http://www.secure...
I definitely think you're right that a dedicated security inbox would be helpful. Even better would be a dedicated .gov-wide security inbox. I don't know how difficult it would be to establish something like that, but it would give security minded folks who care about improving things an outlet for sharing these sorts of details, and hopefully help get things fixed.