Recently phpbb got hacked. Then, I just read the slashdot post How To Argue That Open Source Software Is Secure?.
Would a bank not have a safe with secret access codes just because it has installed the latest high-tech surveillance system?
What I am trying to say is, if a closed source software company argues that “hae, our software is likely to be more secure than an open source code because we don’t give out the implementation details”, then all things being equal, it’s a very compelling competitive advantage as far as security is concerned. Of course, “all things being equal” is not true. For example, the time to respond to a security bug for a commercial software might be more than for an open source code. This is because the number of eyes that can look at the code and fix the issue is a lot for open source project. But do note that the number of eyes that can look at the code and identify potential loop holes are also plenty.
So, I think it’s important for each side of the aisle to realize that their philosophies offer different comfort levels to their customers rather than each one expecting the other side not to consider their philosophy has any weakness.
For everyone who is designing a website, please never never send a password in the registration confirmation email. I usually like keeping these confirmation emails to keep track of all the websites where I ever registered. However, when a website sends a confirmation email that contains the password along with the userid, I delete that email immediately. What is the need to send me my password in plain text? BTW, this just happened to me with ning.com.
In addition, learn about one-way encryption and never save the plain password. Password should never be “retrieved”. If the user loses his password, he should be able to reenter a new one. Just send a email with a long unique key that no one can guess and when accessed through such url, let the user enter a new password.
You can’t call a system secure unless it’s really secure. Any application that does validation on the client side of the browser can’t afford to bypass it on the server side because someone can always programatically post invalid data. Long back when the app servers and http sessions were just coming up, a few e-commerce applications implemented shopping carts and item pricing using html form hidden variables and got hacked.
Anyway, I am trying to understand the security aspect of using Amazon S3, Amazon’s Simple Storage Service. When a system stores a resource locally, it has the control over serving the resource by authenticating the user. However, when using Amazon S3, this is usually not the case. That is, the very reason most people want to use Amazon S3 is for scalability. This can be achieved only if the url points directly to the Amazon S3 servers itself rather than pointing to your own server. If the url is routed through your own server, then you can do a server-side fetching of the resource stored in Amazon S3 after authenticating the user and then send it. But that defeats the purpose completely since your server becomes a bottleneck. Also, in that case, why store it in S3 and not locally?
Amazon S3 offers query-string authentication mechanism. This passes 3 additional URL parameters, your Amazon Web Services Access Key, Expiration and the Signature which is encrypted string of the resource url and a few other details. This guarantees that a resource is not accessible unless the signature is available, but the moment the url is given to one, and anyone else with an access to the url (which can happen in various ways) can also access the resource. So, essentially there is no user level security. The expiration field (which is also part of the signature, encrypted and safe) offers some level of defense, but still may not be good enough for certain class of secure applications.
So, it’s important to understand the limitations of using an OnDemand Service for powering up your applications. Amazon S3 as a personal backup drive is no brainer. Similarly, using it for completely public access also is no issue. Just those applications that require a tight security based on user (and not just based on the resource itself), can’t make use of S3. This issue is not specific to Amazon S3. Any service, with simple operations as those available in Amazon S3 WebServices will have this issue.