61–70 of 172 posts
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.
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…
What channel is that? As an app developer, it sounds useful.
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.
As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for a man-in-the-middle attack because they cannot just take your hash from one of your requests since it will be invalid after received or if some time has elapsed.
For an example, see how Knox sets up requests for Amazon AWS: https://github.com/LearnBoost/knox
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.
When I have a simple app send a password to the server, I like to generate a hash on the client side and then rehash again on the server for storing. As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for…
I'm confused. What do you do with that hash then?
Earlier quoted context omitted.
When I have a simple app send a password to the server, I like to generate a hash on the client side and then rehash again on the server for storing. As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for…
> I like to generate a hash on the client side I'm confused. What do you do with that hash then?
Earlier quoted context omitted.
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…
@Killswitch Problem is PHP is a templating language, not a generic purpose one. Other languages use frameworks for webdevs that usually provide basic security features like auto escaping output,orms by default(so no sql strings),csrf on forms... PHP doesnt ,so it's easier to shoot yourself in the foot.
Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month... Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
The post gave no indication how Cricketer was storing the passwords. They may very well be stored encrypted.
You can send plain text passwords back if you've encrypted them, you just have to decrypt them first. There's no point at all in returning the results of encrypting a password if the clients don't know how to decrypt those results. Given that the API uses plain text HTTP, I doubt that the passwords are encrypted.
What the passwords are not stored as however, are hashes. A hash is not the same as text that was encrypted. A hash is a difficult to reverse unique identifier for bit of text.
Having said all this, it is funny to see your post, and all its replies making fun of security incompetency while also being incompetent in themselves.
Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month... Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
" Who the hell thinks it's OK to store non-encrypted passwords in this day and age?" You'd be surprised: http://plaintextoffenders.com/ ...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month... Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
Non-encrypted passwords are an artifact of legacy systems, and some modern businesses believe that the risk of plain-text passwords being leaked is lower than the risk of systems breaking due to updating passwords/authentication to an encrypted schema. Some modern businesses don't make the best decisions.
There is no excuse --no excuse-- for storing passwords in plain text. Anybody who attempts to justify it deserves a swift thwack in the back of the head.