71–80 of 172 posts
Earlier quoted context omitted.
> I like to generate a hash on the client side I'm confused. What do you do with that hash then?
It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
Earlier quoted context omitted.
> I like to generate a hash on the client side I'm confused. What do you do with that hash then?
It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
As skyebook said, use HTTPS. There's no excuse.
Earlier quoted context omitted.
It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
Sending a straight hash of the password is no more secure than sending the password in cleartext - an attacker can just replay the hash they sniffed off the network. As skyebook said, use HTTPS . There's no excuse.
Having said that, do use HTTPS when possible, but keep in mind some corporate environments force proxies that can see your traffic anyway.
Earlier quoted context omitted.
It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
Sending a straight hash of the password is no more secure than sending the password in cleartext - an attacker can just replay the hash they sniffed off the network. As skyebook said, use HTTPS . There's no excuse.
I'm not sure what is worse, the bad API/app design, or the blog post publicly sharing how to abuse it...
Once after having gotten the vibe, I ended up on phone support with the site in question. At some point I was instructed to "log back in with ummmm that uhhh same password you signed up with...." I could tell that my plaintext-dar hadn't failed me that time :)
Earlier quoted context omitted.
@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.
You mean like Symfony, Laravel, etc? Frameworks that a lot of PHP developers use these days...
Short version: http://criticker.com sells access to their API for apps. Any API account can retrieve a list of all users it registered on the site, then retrieve the cleartext password for each user it created. There are so many WTFs in this whole situation that it's a wonder criticker has managed to keep the website online. Which is a shame, as it looks like a really useful website.
I dont think you realize how common the WTFs in this situation are. If you are dealing with a reputable company, this is super super WTF. When you are looking at a small website/API someone made for fun or something....It can normally be badly broken in less than 2-3 minutes....and I'm not even that talented like some of the guys out there.
For this reason, I don't think "I made it for fun" or "I made it over a weekend" is a good excuse for such broken security. For tiny new apps, it's easier to use a library that does it correctly than it is to roll your own.
Earlier quoted context omitted.
It's not particularly sensitive data being jeopardized- isn't it just movie reviews?
Given the prevalence of password reuse, exposing user passwords is never a good idea.