111–120 of 172 posts
Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
We apologize for the inconvenience.
And here I was, looking forward to actually verifying if this stuff was true...
If anyone from the Criticker team is here on HN, I'd be happy to help you guys get this resolved -- my company Stormpath ( https://stormpath.com/ ) provides a really secure way to handle user accounts. I'll help you guys integrate, or -- if you prefer, I'd be more than happy to dive into your source and help figure out problems and get them resolved. We have a pretty huge team of security experts, and we're all more…
By the way, the alt-text for the portraits on your "About" page needs to be fixed.
To those of your interested on the topic, leanpub has an ebook you can get for free here: https://leanpub.com/yourapiisbad
Earlier quoted context omitted.
I'm going to say FU to the industry and buy a horse ranch if it is! These were all public documented endpoints and 'worked as intended'. criticker is next-level incompetence, that's pretty much the point.
Well saddle-up, my friend ;-) In seriousness, recall the weev/AT&T case[1]. As I understand it, the attack was roughly of the sophistication of making a totally unauthenticated request to: get_user_email_address.php?id=N (where N was from a series of sequential integers)... and apparently the feds had a colorable argument that N constituted an "access control system", and therefore the act of iterating the entire ser…
Earlier quoted context omitted.
I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help…
You can also include an extra random number in the hash, and require that within the window of acceptable timestamps the random numbers have to be unique. By the way, be aware than hash(string1 + string2) constructions are often vulnerable. hash(hash(string1) + string2) is better for most hashes, I believe. But you shouldn't roll these primitives yourself, either. Just use a proper library.
Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at? While some developers may be able to clearly identify bad practices, best practices may not always be so clear. I'd love to know what a best practice would be for things like authentication to an API and some of the other issues brought up here.
If you can do that, the solution is pretty simple. Do it as you would do it with any website. Simply use https (TLS) to transmit username and password and return a session cookie to use in subsequent requests. Run your API over https only.
If you don't want your users to entrust client software (i.e. apps) with their passwords then use https with OAuth.
The reason why using https alone works well for web apps is that users can trust their browsers. Browsers can know the password and they probably won't steal it.
However, if you provide an API and you expect many different client apps, including some dubious ones, to use that API on behalf of your users then users cannot trust the client software and hence you should use OAuth.
The decision doesn't depend on whether or not your application stores sensitive data, because users often use the same password for different sites. So if you like your users and you provide an API for mobile apps to use, you should use OAuth.
Earlier quoted context omitted.
My day job is web developer and i sit in an IRC channel where roughly half the traffic is making fun of security issues of sites. Such a glorious combination of fuckups doesn't come about that often. I'm honestly more apalled that the passwords are in plaintext than that they expose them like that. I cannot say i am surprised though. A general amount of carelessness, undeserved self-confidence and ignorance is a give…
I'm not sure I agree with ``carelessness, undeserved self-confidence'' but I definitely agree with ignorance. I think the best thing is that people writing code just don't understand the internals of how a lot of web attacks work and why the best practices for security prevent them. I reported two account hijack vulnerabilities on startups this weekend and was met with ``What is CSRF?''. I think the reason for this i…
Interestingly one of the problems I've faced running an OWASP chapter is how to get more developers along to it.
Also security.stackexchange.com can be quite useful
Earlier quoted context omitted.
> You can send plain text passwords back if you've encrypted them, you just have to decrypt them first. Yes, and security-wise that's just a slightly obfuscated version of plain text.
That's not true at all. If you use secure encryption to store plain text, and proper use of HTTPs to transfer said text, that's secure. It's not as bad as obfuscated text. What you've said is just plain untrue. One problem with storing passwords is that there is no good reason to. The other security issue is that people reuse passwords. So everyone should be creating hashes instead of encrypting passwords, but encryp…
Earlier quoted context omitted.
You can also include an extra random number in the hash, and require that within the window of acceptable timestamps the random numbers have to be unique. By the way, be aware than hash(string1 + string2) constructions are often vulnerable. hash(hash(string1) + string2) is better for most hashes, I believe. But you shouldn't roll these primitives yourself, either. Just use a proper library.
Do you have specifics on why strcat would be vulnerable? Or is it just because "abc"+"def" == "abcd" + "ef"?
Despite the warning to the company back in 2010, I'm not sure he should be publishing this. He's putting the 2000-odd users at risk by teaching us how to get their passwords and usernames like that, it's even worse if we can get at email addresses too. I would bet the majority of those registered reuse the passwords.
Weev was convicted to 3.5 years in prison for calling a public API with lots of different keys:
http://arstechnica.com/tech-policy/2013/03/auernheimer-aka-w...
In the UK, Daniel Cuthbert was convicted for typing "../../../" in his address bar: