51–60 of 61 posts
A vulnerability in Google Mail that would let you break anyone's account? A six-figure finding. High-profile stupidity (like people with trivially guessable password reset questions) aside, nobody has more incentive to protect your email than Google, Yahoo, and Microsoft do. They're probably better at it than some startup is, too; they've sure spent enough on it.
This is out of my field, but how do you all think this will be compromised? My guess would be by spoofing the CEO's home IP & cookie to bypass the verification, based on this paragraph from the site: "Plus, users only need to receive a verification call when they are logging in from an unrecognized computer. When logging in from a home or work computer, a cookie can be stored so that no verification call is required.…
Assuming that they use a strong enough cookie (eg, containing a randomized unique key that's verified by the server) and all connections are made over SSL, it should basically be as resistant to remote attack as the person's cellphone (eg, SIM chip spoofing to get two cells on the network under the same call number). I say that here, the weak points are the user and the cellphone; I think that the barriers to usage t…
This is out of my field, but how do you all think this will be compromised? My guess would be by spoofing the CEO's home IP & cookie to bypass the verification, based on this paragraph from the site: "Plus, users only need to receive a verification call when they are logging in from an unrecognized computer. When logging in from a home or work computer, a cookie can be stored so that no verification call is required.…
Earlier quoted context omitted.
I guess my point is: if you find a security hole in this service, why would you give it up for $10,000?
Sell it to as many customers as you can find first, and then go to them for the extra $10,000. You get more money than you would have otherwise, and you also save innocent people from being unduly compromised. It's a win-win situation ;)
"I have found a critical vulnerability in this application, which I will demonstrate under NDA to any reporter who requires verification. I will under no circumstances reveal this vulnerability to the vendor or to any other party."
The problem is that folks in security tend to forget that they have to pay attention to the business side of things. It's e-mail.
A certificate plus pass-phrase, and a three attempt fall-back to mandatory phone authentication would be way more than enough assuming that everything under the hood was sound (DNS, SSL, etc ... which have all been shown to have weaknesses recently). Why hammer your way through a steel door when you break open the single pane window in the basement.
Earlier quoted context omitted.
So, based on the edit, how should small startups (or Open Source projects) reach out to security pros? Some Open Source projects have millions of users, and so security is obviously a concern...I've noticed in our own project that we occasionally get penetration testing reports from security companies out of the blue (I guess because Webmin is high profile enough, and is potentially dangerous enough, to be on everyon…
I've never felt comfortable talking about this here before because I have zero interest in trying to make money off companies that need to conserve every dollar they've got. Been there. Recently. It's really kind of tricky. I've been working with my team for the past couple months on an "Indie SDLC" (SDLC is the industry's jargon term for secure development); we gave a talk on it at C4 last August. Rentzsch may post…
3. Avoid a set of "features that always doom dev teams", including encryption, password storage, browser plugins that inject into the DOM, templating, installers, network listeners, and file upload/download.
We're doomed. All but two of these are present in every one of our projects. (I kid about being doomed. Mostly. We do have 11+ years of being a prime target for attacks to give us some confidence that we're doing OK. But we do unavoidably have to handle most of those features that always doom dev teams.)
5. Screw with amateur web pests --- use your own magic version of base64 with some of the characters swapped, use 3DES for something with swapped-around s-boxes, etc.
Isn't fiddling with the encryption, without understanding, what got Debian into trouble a while back with OpenSSL? Perhaps I don't even know enough to know what you're suggesting when you say "3DES with swapped-around s-boxes".
Buy a copy of Burp Suite and run the "Intruder" on every page.
I'd never heard of Burp Suite before. I had no idea there was an automated tool for this stuff (and at a reasonable price). Awesome.
Earlier quoted context omitted.
Assuming that they use a strong enough cookie (eg, containing a randomized unique key that's verified by the server) and all connections are made over SSL, it should basically be as resistant to remote attack as the person's cellphone (eg, SIM chip spoofing to get two cells on the network under the same call number). I say that here, the weak points are the user and the cellphone; I think that the barriers to usage t…
Unless you're incompetant, cookies aren't compromised by guessing them or by scooping them off the wire. They're compromised by cross-site scripting and XSRF attacks.
He'd be a pretty good target if you were looking for someone to mug. Steal his cell phone, collect $10k.
And he posted his office address at the end of the blog post!
Earlier quoted context omitted.
I've never felt comfortable talking about this here before because I have zero interest in trying to make money off companies that need to conserve every dollar they've got. Been there. Recently. It's really kind of tricky. I've been working with my team for the past couple months on an "Indie SDLC" (SDLC is the industry's jargon term for secure development); we gave a talk on it at C4 last August. Rentzsch may post…
Excellent checklist. Several things I never even thought of. 3. Avoid a set of "features that always doom dev teams", including encryption, password storage, browser plugins that inject into the DOM, templating, installers, network listeners, and file upload/download. We're doomed. All but two of these are present in every one of our projects. (I kid about being doomed. Mostly. We do have 11+ years of being a prime t…
* You can intercept them in the requirements phase and either refactor your design so you aren't as exposed to them (maybe you don't really need file upload, maybe you can use S3, etc).
* You can make sure junior devs don't get assigned the scary features (a big chunk of the stupid flaws we find are accompanied with the "oh that was the new developer who did that" excuse).
* You can triage those features in code review and QA.
There is a big but apparently subtle difference between "encryption you rely on" and "rubber chicken encryption" (you can see now why I'm not in love with our Indie SDLC yet). Yes, you never want to dick around with encryption for your single-signon tokens --- use GPGME or Keyczar or something. But once you've secured your app, you can add obfuscation to reduce the likelihood that people will jump on your mistakes.
And yes. If you sell a web app commercially, you should own a copy of Burp. For what it does, it's amazingly cheap (like $150). It is the industry standard web pest tool.
Brute force it. 5 chars... all numeric. There can only be 100,000 possibilities. Of course, they may have logon limits to prevent this. 10^5
3 chars. There are only 1,000 ~ 250,000 combinations depending on if they are alphanumeric or not, and if they are case sensitive.
They should make the key expire after about a minute (or 3 attempts) to slow brute forcing.