Yeah, if you wanted to make the effort. Ease of use was definitely the primary metric being optimized here. Perhaps it's not as important to have a short, speakable URL; in which case it could be a SHA1 hash or something. Maybe URL shorteners can play the above role if needed. What do you think?
Obscuring the URL from brute forcing would make it difficult to find random information site-wide (but using a hash is probably asking for trouble; just generate a long random string).
However, if I knew a specific person were using this service (which, since this is a public website whose URL you share with one or more other people), I could find other ways to find it and then break the application or server behind the firewall and have access to a multitude of juicy information to steal. It's kind of like saying to an attacker: "hey, instead of attacking a random web server you could attack the developer's workstation!" Black hats like lulzsec, etc would have a ball.
I recommend a simple username/password combo at the very least to prevent unauthorized access. The whole 'access-behind-the-firewall' concept still gives me the heebie jeebies though, and I think short of a VM on the developer's workstation I would be very afraid to use such a service.
Comments
Yeah, if you wanted to make the effort. Ease of use was definitely the primary metric being optimized here. Perhaps it's not as important to have a short, speakable URL; in which case it could be a SHA1 hash or something. Maybe URL shorteners can play the above role if needed. What do you think?
Obscuring the URL from brute forcing would make it difficult to find random information site-wide (but using a hash is probably asking for trouble; just generate a long random string).
However, if I knew a specific person were using this service (which, since this is a public website whose URL you share with one or more other people), I could find other ways to find it and then break the application or server behind the firewall and have access to a multitude of juicy information to steal. It's kind of like saying to an attacker: "hey, instead of attacking a random web server you could attack the developer's workstation!" Black hats like lulzsec, etc would have a ball.
I recommend a simple username/password combo at the very least to prevent unauthorized access. The whole 'access-behind-the-firewall' concept still gives me the heebie jeebies though, and I think short of a VM on the developer's workstation I would be very afraid to use such a service.