6 ms·
believe it or not, this was intentional and an homage to slashdot (the concept of having low IDs that are publicly viewable), however obscure the public link f
by dhouston 17y ago
believe it or not, this was intentional and an homage to slashdot (the concept of having low IDs that are publicly viewable), however obscure
the public link feature was actually a proof of concept and never intended to stick around :)
but anyway, having this information doesn't let you do anything but get a rough count of our users, so saying it's a security issue is a stretch. there are no public-facing forms or inputs that take these values as input
- krishnole 17y ago@dhouston, Thanks for the little info about the motivation behind using this approach. However, I want to point out that I never said it is a security issue. I just said that it is not a best practice from the security point of view and it could be taken as a starting point for further poking and social engg stuff. I just want to make it clear here.
- tptacek 17y agoYou didn't read his comment carefully. He refuted you. According to him, there's no further poking to be done. "There are no public-facing forms or inputs that take these values as inputs". Not only that, but the title of your post was "SaaS Vendors Should Learn The Art Of Security Before They Open Shop". It's a bit late to walk the sentiment back now. Either come to the table with more information than you've shared, or take your lumps and apologize. I think you got it wrong.
- krishnole 17y agoI did read his comment. Since, he is not refuting the issues I (or, for that matter, the guy who did the analysis) raised, I didn't respond. You don't need to have further forms or any other input. Just the list of account numbers, educated guesses about filenames like resume.pdf or resume.doc, then digging out info from such filenames, then social engg techniques, etc. could cause enough havoc to the individual. The same line of arguments can be applied to businesses as well. Plus, anyone who has read my post properly (than asking me to read the comments here properly) can understand that I never said that their security is weak. I only told that their approach to resource enumeration offers an easy way for hackers to get started. I am not sure if you understand the argument I am making here from a purely security point of view. But, if you are familiar, I invite you to think along these lines and see if it is a good practice to have this kind of sequential naming system. PS: Regd you second paragraph, I don't respond to childish talk. If you restrain and talk like an adult, I am happy to discuss this issue. This is not about me or you or Dropbox people, it is about possible issues such an approach can cause and its impact on cloud computing, in general. Since, I evangelize cloud computing, I care about issues like this and try to highlight it in my blog posts. If you are open to mature discussions on this topic, feel free to drop by my blog post and we can discuss further. Otherwise, this will be my last response. Thanks for your time anyhow.
- krishnole 17y agoLet me put it this way. If I am a business and if I knew that there is an easy way for a hacker to reach the documents I am sharing to selected few publicly (the key point here is the EASY WAY TO GET to my account), I will be worried about sharing my documents through that service. I do agree that any publicly shared document in any service is vulnerable but the question here is the ease at which it could be found in a service.