The users aren't the idiots here, they had no reason to assume their private pictures would be shared (and even if you put a disclaimer on there, you can't expect people to read that). Besides, the admins of the service must have been fully aware people were sharing sensitive pictures, and they did nothing about it! And it wasn't a public URL, it was a URL secured by a lousy hash. Virtually indistinguishable from a URL generated by Google Docs.

I think your statement (where you call the users idiots) represents everything that's wrong with the current security-lax web services crowd.

     If you launch something like QuipTxt, make it obvious to 
     people that their images are public

Google Picasa stores images as public URLs without any such warning. Because with random URL's, you effectively have passworded each image. Even more secure than if they were all locked into a nice MySQL database, because then they would all be behind only a single password.

I think you don't have to freak out users with too much information. The images are effectively password controlled.

The problem here is that the passwords were too short (and sent in plain text via SMS).

Yes, but passwords are typically used as a form of authentication (i.e. something you know) - to prove the identity of the user.

Once a user has authenticated themselves then it is a separate problem to decide what they are authorized to see.

Even really complex keys in links are still a big problem as they are far too easy to pass around - I've seen multiple problems on commercial systems and products where documents didn't require authentication before access and "security" relied on having an obscure key value directly represented in a link.

Sure. When you leave passwords floating around in plain text, bad things will happen too. It's too easy to forget that an obfuscated URL needs to be treated as a password.

if you only need to guess something address to see it, it is public

The average Google Docs link has more entropy than the average username/password combination. So unless you want to argue that everything online is public to some extent, I don't think your claim makes much sense.

the google docs links arent stateless logins, you cant login to google as me because you guessed the hash of my word doc (or more likely, I gave it to you).

I disagree.

A password is not a magic spell. It's a set of letters and numbers that, if guessed correctly, will give me access to something you wanted kept private.

An obfuscated URL is a set of letters and numbers that, if guessed correctly, will give me access to something you wanted kept private.

Because one uses a MySQL database, and the other uses a file system, is irrelevant. They are functionally identical when directory listing is disabled, as it can be for Amazon S3.

Locks on houses aren't infallible either, but establish intent: "you should not be here". Very short hashes don't do that quite so much.

I'd be interested in knowing what the length a hash needs to be to communicate "you should not attempt to circumvent this and post the nude pictures behind it", and also how secure a lock needs to be to communicate "you should not attempt to jimmy this with a credit card and post the nudie pictures behind it."

Well, to tell the truth, if there's a 'lock', it's pretty obvious you shouldn't be doing it. If there's just a hash, it strikes me as simply a bad idea in the first place, no matter how long it is. Someone can just do 'copy image url' and have it work, with no challenge from the application. A shorter hash is especially bad because it makes them easy to guess at. I'm not saying it's "right" to copy images protected only with a hash, but it's like leaving an expensive bicycle unlocked on a college campus in the US - it's simply not very prudent. Of course in this case the users probably weren't aware of the problem, and the people who made the application are at fault.

Edit: like daleharvey says, the point is really that the hash simply happens to be difficult to find, whereas a proper application will challenge everyone who attempts to access the resource. For instance, say Alice looks at Bob's picture, and does "copy image url", and sends it to Carol. Carol has no way of knowing whether it's supposed to be private or not, since Alice didn't communicate that information.

A password can usually be changed if compromised, and a password system usually contains measures to prevent brute-forcing; like cooldown times and a lockout after three guesses for example.

If you build those same measures into your URL then they have the same level of security; plus you can make your URL key a lot longer than would be comfortable for a password.

its not about filesystem vs database, where the data is stored is arbitrary, its about how much information you need to access it, apart from the increased entropy in using 2 bits of information (a username + a password (depending on the link size)), you can also implement things like locking accounts when someone guesses the password wrong X times, something that is impossible with a single entry point.

Hmm, with that logic, all private Facebook albums, EtherPad documents, MySpace images, and [insert obviously private thing here] are also public.