4

If I have a script I want to be able to run at a moment's notice and have it on the public side of the server on https, and as long as I keep my own personal cache from prying eyes, is that as secure as a 'behind the public' script in which I would have to log in with a username and password to instantiate?

For example, consider these two methods:

1) I log in with username: xxxxxxxx, password: yyyyyyyy (say with ssl or cpanel and then trigger the script)

2) I simply run this path from my iphone, https://www.iamsilly.com/xxxxxxxx/yyyyyyyy/myscript.php

Eliminating the possibility that someone might pick up my iPhone and look in my history, is there any practical difference between the level of security between these two systems of security? Is the complexity not exactly the same? Is https not encrypted enough to make the https complexity just as safe as logging in?

Thanks, I apologize if this topic has been talked to death, but after reading oodles of posts about it, I still don't quite get it!

EDIT: Keep in mind that the path with an 8x8 randomized double directory has 7 quintillion (seven billion billion billion) combinations, and that's only if I were to use alpha and numeric characters.

Andy Lester
  • 91,102
  • 13
  • 100
  • 152
Rickaroo
  • 67
  • 7
  • possible duplicate of [If you use https will your url params will be safe from sniffing?](http://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing) – Explosion Pills Nov 27 '12 at 05:13
  • Https only involves encrypting the connection from the server to the end device. This prevents the traffic from your server to the client browser from being transmitted in plain text. It is just like http except outsiders cannot view the traffic. That's it. – kermit Nov 27 '12 at 05:45
  • However: If the ability to list directory contents is turned off at the web server, it seems that it will very difficult for an attacker to guess the directory names. Especially if you have unusually named directories. The correct "official response" is, "No security through obscurity" but... isn't guessing passwords like trying to guess directory combinations? – kermit Nov 27 '12 at 05:55
  • You should use username/password and obscured path :) Security in depth approach is always better. Secondly watch out for paths because they are logged by default in apache logs, and IEEE found it the hard way: http://www.esecurityplanet.com/network-security/ieee-suffers-massive-security-breach.html – damiankolasa Nov 27 '12 at 07:00
  • @fatfredyy - From that article, "they failed to restrict access to their webserver logs"... I would say the problem was with someone allowing access to the webserver logs, not a failure of an obscurity construct. My question here is about why a username and password to 'log in' is more safe than a path with the same entropy. In IEEE's situation, could anyone hacking the username and password to gain access to the webserver logs not then have direct access to the logs and therefore the script? – Rickaroo Nov 27 '12 at 14:33
  • Thank you @kermit, you've shown me at least one other person understands the question I'm asking. I wish someone could specifically tell me in 20 words or less why it's easier to 'find that path' than it is to 'log into the system' by someone who goes in knowing nothing about it. – Rickaroo Nov 27 '12 at 14:38
  • The difference is the treatment of the data. Passwords are obviously sensitive information, so they will be treated with caution by people as well as software. URLs however are typically not security critical, so they are logged, saved to history, copy and pasted, linked to from other sites, not hidden from proxies, shown in browsers' location bars, ... – Niklas B. Nov 27 '12 at 15:01
  • Another important difference is that a webserver does not need to know a password to authenticate a user (and therefore, MUST not save the password, at least in my opinion). It can check the hash of the given password against a hashed version of the saved password. To simulate that behaviour, you'd need to use URL rewriting anyway, so you even lose the advantage of simplicity. Also, if you use random passwords, you can bet that your users will just write those URLs down somewhere or even save them on their hard disk, because they can't memorize them – Niklas B. Nov 27 '12 at 15:09

3 Answers3

8

You're saying "I don't need to lock my front door if it's not visible from the street, right?"

You're assuming you know how a given intruder will find his way to your site. You don't.

You're assuming that a single human being is trying to get into your site. It probably will not be a human, and it probably won't be just one. Intrusion attempts scale up very well.

I put my seat belt on in the car no matter where I'm going, even if I'm literally driving a quarter mile away. It's safer and I don't waste brain time wondering if I need to. Put the password on your app and don't waste your time trying to figure out if it's worth it or not.

Andy Lester
  • 91,102
  • 13
  • 100
  • 152
  • 4
    Here's an example of an attack that I bet OP hasn't thought of: Using JavaScript to sniff the history and pass it to badguy.com http://security.stackexchange.com/questions/17873/workarounds-for-visited-css-history-reconnaissance – Andy Lester Nov 27 '12 at 15:41
  • Assuming that you are on Apache, using htpasswd isn't hard. http://httpd.apache.org/docs/2.2/programs/htpasswd.html – MikeHoss Nov 27 '12 at 16:13
  • No, I'm saying my house has 7958661109946400884391936 doors. Haha. And if I made the path http://www.mysite.com/xxxxxxxxxxxx/yyyyyyyyyyyy/script.php, then my house would have 7958661109946400884391936 doors. That's a lot of doors. And only one opens. But thanks anyway, I do appreciate everyone's input! :o) – Rickaroo Nov 27 '12 at 19:36
  • 1
    You're assuming that the only way someone can find that URL is by guessing. It's not. See that link I posted above for a JavaScript hack to give a bad guy knowledge of visited sites. – Andy Lester Nov 27 '12 at 19:52
  • 1
    I'm starting to see what you are saying and I am starting to agree... however, as far as I can tell, the JavaScript hack above needs to supply a list of links that it gets a yea or nay as having been visited. I think that is the same as guessing. I will password protect these scripts for sure. thanks all! – Rickaroo Nov 27 '12 at 21:28
  • 3
    Yes, *that* specific hack requires you to supply a list of links. However, you didn't know about it, did you? That's my point about the danger of thinking you know how you'll be attacked. – Andy Lester Nov 27 '12 at 21:35
  • 1
    Touche. Thanks @Andy, I think it's finally sinking in :o) – Rickaroo Nov 28 '12 at 14:28
2

No, Security through Obscurity is no security at all.

GreyBeardedGeek
  • 29,460
  • 2
  • 47
  • 67
  • 1
    Directly from that page... "There is scant formal literature on the issue of security through obscurity. Books on security engineering will cite Kerckhoffs' doctrine from 1883, if they cite anything at all." – Rickaroo Nov 27 '12 at 14:27
2

I think the answer is "How bad would it be if someone did manage to get hold of this?" then act accordingly.

"That would never happen" always makes me paranoid.

Joe McMahon
  • 3,266
  • 21
  • 33
  • 1
    I agree. I agree about the seat belt thing too, as mentioned by @Andy Lester. This may be a matter of teaching an old dog (me) a new trick (being paranoid). I think the moral of the story here may be that paranoia can finally work in my favour. :o) – Rickaroo Nov 28 '12 at 06:56