Security by obscurity?



  • I often hear this phrase from knowledgeable individuals but never in a context of a username/password protected system. Isn’t that the ultimate “security by obscurity" security? Anyone knowing the username/password combination can get in. Security stems from the fact not everyone knows it.

    Is there a fundamental difference between a login control and a secret url?



  • @ Angstrom - If someone has access to your code I'd guess he has access to your db.



    In any case I could develop a web based security solution where typing
    &admin=true in the url gives you admin priviledges without it being
    obvious from the code itself. Eg. the "true" part might be compared to a
    value stored in the db.

    								</span>


  • Having a manual addition to the URL is slightly worse than a username/password system, as it is effectively just the password. Add to that the fact that the URL is cached locally, visibly in server, proxy and browser logs, and you have yourself one nice security hole.

    To answer your original question, security by obscurity is in no way like not knowing the password. Security by obscurity relies on the fact that the only reason a person cannot get admin privileges is that they do not know how the code works. If they were ever to find out (as in your &admin=true example) then they could get full access. No extra knowledge beyond the workings of the system is required.

    Username/password security, pub/priv key security, and other related types are different because you can have full and in depth knowledge of how the system works, and still not be able to get in. You are protected because data that is not an inherent part of the system is required.



  • @craiga said:

    Having a manual addition to the URL is slightly worse than a username/password system, as it is effectively just the password.

    One could argue username/password is just a large password.

    @craiga said:

    Add to that the fact that the URL is cached locally, visibly in server, proxy and browser logs, and you have yourself one nice security hole.

    Agreed. I can still argue this is users fault for not clearing his history - most current browsers enable you to store your passwords within their password managers.

    @craiga said:

    If they were ever to find out (as in your &admin=true example) then they could get full access. No extra knowledge beyond the workings of the system is required.

    As I tried to explain - the true part might be a value in db. To get admin privileges you would have to guess that correct url is "?admin=34710". This value could be modified daily and provided to users via encripted channel.



  • @nonDev said:


    As I tried to explain - the true part might be a value in db. To get admin privileges you would have to guess that correct url is "?admin=34710". This value could be modified daily and provided to users via encripted channel.


    From a technical point of view, there is almost no difference between a url like "http://www.foobar.com?admin=34710" and a url like "http://www.foobar.com/login.foobarscript?username=admin&password=34710", the later one resulting from a "method=get" form. Both are equally bad. There are too many ways the url can escape to the wild.



  • @nonDev said:

    As I tried to explain - the true part might be a value in db. To get admin privileges you would have to guess that correct url is "?admin=34710". This value could be modified daily and provided to users via encripted channel.

    URLs are not in and of themselves, encrypted, however, so anyone using that URL is effectively exposing your username and password to anyone with a packet sniffer between your server and their host. Sure, the likelyhood that someone is watching you is probably small.... but are you willing to take that chance?



  • @nonDev said:

    @ Angstrom - If someone has access to your code I'd guess he has access to your db.



    In any case I could develop a web based security solution where typing
    &admin=true in the url gives you admin priviledges without it being
    obvious from the code itself. Eg. the "true" part might be compared to a
    value stored in the db.

    								</span></blockquote><br><br>On the other hand, if I tell you my website (which uses HTTP authentication, just for examples' sake) runs apache 2.0.x with modules x, y, and z installed, you can review the source yourself and still not have any idea how to bypass security unless apache or one of the modules is actually flawed.<br><br>Using an admin flag in the URL, whether it's "admin=true" or "m=longhexvalue", is broadly similar to having a single shared administrative password, with all the administrative issues that go with it.<br>


  • @nonDev said:

    One could argue username/password is just a large password.


    You could, but you'd be wrong. Username is for identification, password is for authentication. In the simplest of all simple cases, where the system has a boolean 'you are admin or you are not admin' condition then your assertion is true. In all other cases it is false.

    @nonDev said:
    Agreed. I can still argue this is users fault for not clearing his history - most current browsers enable you to store your passwords within their password managers.

    And all those naughty sysadmins for not clearing their access logs? You CANNOT rely on user action or inaction for security. If the system is vulnerable at ANY stage, then it is vulnerable always.

    @nonDev said:
    As I tried to explain - the true part might be a value in db. To get admin privileges you would have to guess that correct url is "?admin=34710". This value could be modified daily and provided to users via encripted channel.


    You completely miss the point. By having a password in a database, you move away from security by obscurity into a slightly (but only slightly) higher form of security. Security by obscurity is security that can be compromised by knowledge of how the system works. If you are reading from a database, then no matter how well you know the system, without access to that database you are still locked out. With a simple 'admin=true' system, all you need to know is the backdoor.

    Consider the various encryption algorithms used for PGP, GPG, SSL and the like. You could have a perfect working knowledge of those algorithms, but without the private key of the intended recipient you cannot decypher them. This is a perfect example of true security. A bad encryption algorithm is one that can be decrypted with knowledge of the algorithm alone.



  • @craiga said:

    Username is for identification, password is for authentication.

    I fail to see the difference as far the security system is concerned. Authentication process takes the input and checks against a db of valid values. There is no difference in systems that check one, two or fifty values that must match-up.

    @craiga said:
    You CANNOT rely on user action or inaction for security. If the system is vulnerable at ANY stage, then it is vulnerable always.

    I'm not arguing that is the case. I'm nut using or implementing such systems :). What I am arguing is that a simple username/password security is an "security by obscurity" system.

    @craiga said:
    You completely miss the point. By having a password in a database, you
    move away from security by obscurity into a slightly (but only
    slightly) higher form of security.

    English is not my native language but I still think I made myself clear. Lets try and make this clearer. Lets say you do have a db filled with values that authenticate users. Lets replace the misleading url with ?user=34710. Lets say the system looks it up in the db and authenticates you as a valid user with certain privileges. If you manage to guess 34710 you're an admin, if you guess 3209 you are a user and if you type 34711 you do not login.

    @craiga said:
    With a simple 'admin=true' system, all you need to know is the backdoor.

    Correct. And with common username/password systems you need to know the username and password "backdoor". How different is knowing 34710 from admin/38c_xz?

    In all these cases the only thing standing between an intruder and your system is the value (or values) stored in db that your users know and your intruders do not.



  • @nonDev said:

    In all these cases the only thing standing between an intruder and your system is the value (or values) stored in db that your users know and your intruders do not.

    And these are not security by obscurity.

    As it's already been explained, security by obscurity means that access to the code is equal to being able to break the software without any more knowledge required. I find the cryptography/hashing algorithm a good example of not security by obscurity: let's say that you know by heart the SHA-512 algorithm (it's public after all), can you more or less instantly crack it because of this? No. You'll still have to use brute force as if you didn't know the code, or look for collision algorithm and look for weaknesses, which can be done without the code anyway.

    In this case, you're not talking about security by obscurity: access to the source code of the software doesn't grant you more or less automatic access to any install of the product, you need access to the DB (or use brute force/dictionary attacks, which is another issue), which is an insider access to the installation itself, not a weakness of the product.

    And another thing, anyone stupid enough to use GET HTTP action (aka URL) for identification/authentification needs to be shot.



  • @masklinn said:

    .. let's say that you know by heart the SHA-512 algorithm (it's public after all), can you more or less instantly crack it because of this? No. ... And another thing, anyone stupid enough to use GET HTTP action (aka URL) for identification/authentification needs to be shot.


    Yes, I think that sums up what I was getting at nicely :-)



  • Here's an interesting question for you, nonDev; if, as you say, usernames and passwords are in fact 'security by obscurity' because it relies on secret information, what security system exists (or could exist) that could NOT be classed as security by obscurity for the same reason?

    Just curious as to how you're thinking on this one ...



  • @craiga said:

    Here's an interesting question for you, nonDev; if, as you say, usernames and passwords are in fact 'security by obscurity' because it relies on secret information, what security system exists (or could exist) that could NOT be classed as security by obscurity for the same reason?

    Just curious as to how you're thinking on this one ...


    Well, biometric systems would not rely on secret information, but on unforgable well-known information.



  • @craiga said:

    Just curious as to how you're thinking on this one ...

    I found this article quite interesting: http://msdn.microsoft.com/winfx/reference/infocard/default.aspx?pull=/library/en-us/dnwebsrv/html/lawsofidentity.asp

    It's interesting that almost everything  on the web relies on "a secret".

    How about an ip check? Let's say you are using a service that makes sense being used only in a specific area (How many of you do online banking from out of state?). Now your security relies on "a secret" and "a location".

    How about loging unsuccessful logins. Would your users mind if you send them a helpful e-mail saying something along the lines of: "We noticed you have attempted to login with an invalid password several times this week. Did you wish to have your password reset?".

    How about loging succesful logns and looking for things out of pattern? ...



  • "Security by obscurity" is a commonly used term, meaning security based
    strictly on nobody knowing about your security setup.  For
    example, a bank relying on nobody knowing where the money is stored,
    instead of storing it in a safe.  Or a web site relying on nobody
    knowing the administrative URL.


    The problem is that, if the value is great enough, you can be sure
    someone will learn your procedures.  Since those procedures must
    be followed to fulfill commitments (the bank loaning out money, or
    administering your website), they can be monitored.  If they can
    be monitored, and the value is greate enough, they will be monitored.


    This is not to say that security by obscurity cannot work.  It can

    • as long as nobody knows that you exist.  But as soon as anyone
      your existence is realized, your entire security scheme has gone out
      the window. And the more people you contact, the more likely it is that
      someone will notice you have value.  And if your value is great
      enough, your security system will be attacked.

    Obscurity does have a limited place in security (such as passwords),
    but relying solely on obsecurity for security (the bank that hides its
    money in the closet instead of the safe) is unrecommended. 


    The trick to properly using security is threefold:  first, know
    what to make obscure; second, make the obscure things very, very hard
    to guess; and third, make them moving targets.  In the first case,
    you (usually) cannot make your existence unknown, while still be of
    value.  Instead, you have to make your data obscure, and you have
    to make the key (password, safe combination, etc) to access that data
    secure.  In the second case, if you have a hard to duplicate key,
    you're safer than if you have an easy to duplicate (such as passwords:
    anyone who wants to guess your password is more likely to do so if your
    password is easy to guess).  In the third case, if your key
    changes often, even when the attacker guesses it right, s/he has access
    to your value for a limited time - once the key changes, s/he should no
    longer be unable to access your value.



    Good security also requires other aspects, such as policies,
    appropriately strong authentication, access control (a.k.a.
    authorization), appropriately ensuring privacy/secrecy of value,
    appropriately ensuring availability of value, and auditing.


    There are lots of good documents available on these topics.  Check
    out www.securityfocus.com, or NIST
    (http://csrc.nist.gov/publications/nistpubs/index.html).



  • Oh, and since several of the posts seem to be cnosidering only authentication, there's a little more I'd like to say about that.





    Authentication - proving you are who you say you are - can be
    accomplished in three ways: something you know, something you have, and
    something you are.  Each of these three ways is called an
    authentication factor.  Each factor has benifits and
    penalties.  Appropriate understanding and use of various factors
    can provide stronger security than inapprorpiate decisions.



    I like to start at the last one first, then work my way back.





    <u>Something you



  • @ammoQ said:

    @craiga said:
    Here's an interesting question for you, nonDev; if, as you say, usernames and passwords are in fact 'security by obscurity' because it relies on secret information, what security system exists (or could exist) that could NOT be classed as security by obscurity for the same reason?

    Just curious as to how you're thinking on this one ...


    Well, biometric systems would not rely on secret information, but on unforgable well-known information.

    In client-server systems, biometrics simply take the biometric information and make a password hash out of them.  If you study the protocol long enough, you can figure out how to respond as a "fake" client and provide forged biometric information.  The only way to make biometrics unforgeble is to use a closed, tamperproof system.

    Expliot example:  My bank implements a new fingerprint based online banking system.  Fingerprint only, no pin.  I study the web page code and find where the fingerprint data gets injected into the form.  I created a slightly modified version of the page that logs that fingerprint data and put the modified page on a server at my house.  I tweak my home DNS server to redirect requests to this new server.  Now, a friend comes and uses the online banking system from my house.  After he leaves, I tweak my page to inject his fingerprint data into future requests.  Then I transfer all his money to my account.
    In order to make this system secure, another layer needs to be added that authenticates the client portion of the application (an SSL certificate would do, but since the client is under my control, I can forge that too).  My point is that biometrics do not add any security to a system, just a lot of convenience.  That is until is gets hacked -- it's really hard to change your fingerprint after someone has hacked a reader and is able to digitally fake yours.

    Most good biometric systems use two-factor authentication.  The biometric data and something remembered.



  • @atk said:



    Something you

    I guess the forum ate your post. Could you repost it please?



  • Something you are, something you have, and something you know.

    Just guessing.



  • Gah.  It did eat my post.  Oh well, here's another
    attempt.  I'm retyping, very dissapointedly, as I really liked the
    way I wrote it last night.  I'm probably forgetting things, but this should make a decent start for anyone interested.




    There's three ways to authenticate yourself.  Each way is called a
    factor:  something you know,
    something you have, and something you are.  N-factor authentication is
    defined as one instance of each of N factors.  So three factor
    authentication would require something you know, something you have,
    and something you are.  If you have two instances of one factor, like
    two Something You Knows, then you still have One Factor
    authentication. 


    Mixing factors allows you to use the good points of one factor to
    lessen the bad points of another factor.  Since the really important
    thing is often knowing that you're being impersonated, the trick is to
    combine factors that (1) make it hard to impersonate you, and (2) make
    it easy to know you've been impersonated.


    Each factor has good points
    and each has bad points.  As I started to say, I like to work
    backwards.



    Something You Are is some feature about you.  It's your face,
    your retina, your fingerprint, or your weight.  Some features of
    you are known to be non-unique (your weight), others are believed to be
    nearly unique (your face (consider twins)), and others are believed -
    but not proven - to be truly unique (your fingerprint).


    There are several benifits to Something You Are:

    • You can't forget (leave it at home, or just not remember it)

    • It's reasonably easy to use (it's hard to fat finger a fingerprint read)

    • You don't have to worry about changing it, like you have to with a password.


    There are also penalties to Something You Are:

    • It's public.  Everything about you is public.  If I want to
      copy your face, I can find your face.  If I want to copy your
      retina, I can get a picture of it (I may need very expensive equipment,
      but if the value that it protects is high enough, it's worth spending
      on the equipment).  Since it's public, I can duplicate it.

    It's hard to match properly.  Much of reading biometrics is as much art
    as science.  Take finger prints, for example.  Every time you leave a
    print, it's different from most other times.  The temperature (extreme
    heat/cold), the surface, dampness of your finger, a healing (or open)
    cut, or anything else you can think of that would affect your print
    will affect your print.  That means that you can't just take a picture
    of it and expect an exact match - there has to be some tolerance in
    there.  If the tolerance is too tight (too close to expecting an exact
    match), "unexpected" conditions (like skin that's too dry) will cause a
    false negative - a misread, causing the reading device to think you are
    not you - and access will be denied to those who should have access. 
    If the tolerances are too lose, false positives will result, and an
    attacker will be more likely to log in as you.

    • It's hard to replace when stolen.  Once I have your fingerprint, I
      have it, and there's nothing you can do.  You cannot replace your index
      finger with another index finger (surgery aside).  You do have 9 other
      prints you can use, but I can copy those, too.

    • It's very hard to replace when lost.  What happens if you get 3rd
      degree burns all over your hands?  What happens if your job requires
      you to work with materials that eat away your prints (such as cement)? 
      What happens if you get in a horrific tractor accident and both hands
      are lost at the wrist?  How do you use a fingerprint login now?



    Something You Have is pretty easy to tackle.  The classic example is a
    credit card.  It's not Something You Know, since there's a physical
    item there - the card number is the important part of the card, but
    it's on physical media, not stored exclusively in your brain.


    Benifits of Something You Have are:

    • It's (usually) easy to use

    • It's private.  While you do share your credit card with lots of
      merchants, they are trusted merchants, and you trust them to keep your
      card secret from The Bad Guys.  Being private, it's harder to steal
      than if it were public.

    • It's easy to match.  There's always an easy way to input the
      Something into an electronic device, and it's always easy to identify
      whether that Something matches your account or not.

    • It's pretty easy to replace.  All you have to do is contact someone, and have a new Something assigned to you.

    • It's easy to tell when it's stolen - it's no longer there!

    • requires physical access to steal


    Penalties of Something You Have

    • It's easy to forget, and leave somewhere

    • It's somewhat easy to steal (picking pockets)

    • It's not completely trivial to replace.  It takes some amount of time
      to replace something you have.  This time could be trivial (go to the
      security desk and spend 20 minutes) or it could be long (7 days for the
      new credit card to arrive in the mail)



    Something You Know is the last factor.  Note that if you take something
    you know, and write it down, it becomes Something You Have, not
    Something You Know.  To be something you know, it must reside
    exclusively in your memory (and, in some form, on the authenticator). 
    Benifits include:

    • Private

    • Trivial to change/replace

    • Rather hard to steal

    • Easy to match


    Penalties of Something You Know:

    • Hard to recognize when stolen.  The only way to know that I've stolen
      your password is to notice that I'm using it from a location, or during
      a time, when you couldn't possibly be using it.

    • easy to forget



    So, as I indicated before, two tricks to making it hard to forge, and
    making it easy to detect when stolen.  This is often accomplished with
    Something You Have combined with Something You Know.  The Something You
    Know is a password, or a PIN.  The Something You Have should be a
    tamper resistant, cloning resistant device (like some of the better
    hardware tokens out there).  You gain the difficulty of stealing a
    password (rather hard) combined with the difficulty of stealing
    something you have (not all that hard, but requires physical access). 
    You also gain the ease of knowing that you might be being impersonated

    • Something You Have is missing!

    Of course, there's much more to making it hard to forge than that. 
    Other things include (as mentioned earlier) making the key a moving
    target, making Something You Have a moving target (such as hardware
    tokens and One Time Passwords), making eavesdropping more difficult
    (encrypted communication channels), hashed passwords on the server (to
    defend against the system administrator impersonating you), and more.





  • @nonDev said:

    Is there a fundamental difference between a login control
    and a secret url?




    In direct response to your original question, as you might now guess,
    the answer is, "Yes!".  As you can see, a secret URL is very
    weak.  It doesn't change, it's interceptable (HTTP over SSL won't
    save you, here - URLs are passed outside the encrypted data), it's
    guessable, and it's got all the failings of Something You Have and
    Something You Know, with very few of the benifits (the only one I can
    think of is that it's secret).  If you want, take identifying the
    failings and the benifits that a secret URL would have as an exercize.



    With a password - or two factor authentication (considered much
    stronger than a straight password) - you start getting more benifits.



  • @jsmith said:

    In client-server systems, biometrics simply take the biometric information and make a password hash out of them.





    I just want to clarify two things in your post.  First, a
    cryptographic hash is a one-way function.  Like multiplying two
    very very very large prime numbers (like 100 digit wide primes) - it's
    very very very difficult to determine the two values that were
    multiplied to get the result.  Cryptographic hashes are often
    based on problems like that, only much harder.  In addition to
    being mathematically infeasable to get the original data back, even two
    very very similar pieces of data will result in widely differing hashes
    (otherwise it would be easy to determine the data by guessing something
    kinda close, then tweaking your guess until it matched perfectly)



    Encryption is taking data, and some key (the key is just an additional
    piece of data, whose length depends upon the particular algorithm, and
    mixing them together in such a way that it looks like garbage. 
    The cool thing about encryption is that you can then use the same key
    (or a related key, depending upon the algorithm used) to get back the
    original data.



    So, your statement about making a "password hash" is not quite clear
    grin.  I suspect you mean a cryptographic hash, but that won't
    work with biometrics.  Since the reader has to have tolerance, but
    the reader itself doesn't know what the match is, the best that can be
    done is to encrypt the data, and pass it to the server.





    The other thing that I want to clarify is (as I stated in another
    post), biometrics are NOT unforgable.  Anything that man can make,
    man can fool.



  • @nonDev said:

    Isn’t that the ultimate “security by obscurity" security? Anyone knowing the username/password combination can get in.

    Is there a fundamental difference between a login control and a secret url?

    One measure that your security system is "secure" is that even if your enemy has a copy of your encoding machine, the messages sent are safe as long as the key used is unknown by the enemy. Or, think of a door. A login control would be like a lock that uses a key. A secret url would be more like knowing just how to wiggle/force the door to open it, without unlocking it (this is far more common than you'd believe, such as sliding windows/glass doors: lift up and it is off the tracks without needing to be unlocked).

    As for fingerprints or iris scans being "secure..." There was a paper presented by some Japanese students on how they made false fingerprints with the same substance used to make gummi bears. They demonstrated that their techniques fooled every fingerprint reader on the market at that time. Most of the copies of the PDF of their presentation have been removed from the web. The same (or maybe following year), a couple Germans demonstrated how to get iris scanners to falsely accept counterfeit irises (hint: photgraphs of enrolled eyeballs, with a hole punched in them for the pupil.

    Some of the other posters pointed out a critical factor about biometrics: you can always give me a new username/password, but you cannot give me a new finger.



  • @atk said:

    It doesn't change, it's interceptable (HTTP over SSL won't
    save you, here - URLs are passed outside the encrypted data), it's
    guessable,

    Yes it can, so is login control data without ssl, I would not say admin=34710 is guessable...

    But thank you very much for reposting. To what category would things like locking account on three wrong guesses fall? I'm not it, I don't have it and, it's not something only i know. Are there any external categories to complement the usual three?



  • nonDev,





    Me (as you quoted me): It doesn't change, it's interceptable (HTTP over SSL won't
    save you, here - URLs are passed outside the encrypted data), it's
    guessable



    You: Yes it can, so is login control data without ssl,



    Me:  You said two things.  As seems to be typical for me,
    lately, I'll touch on the last one first.  The second half of what
    I quoted was "so is login control without ssl".  One of my earlier
    points was that, when you put the login control into the URL, you are
    basically taking the login control outside the encrypted part -
    outside the protected part of the request.  You are doing login
    control without ssl.



    Now on to the first part, "Yes it can".  The URL can change,
    but, when you talk about a URL, it generally means something
    static.  Yes, technically CGI arguments are part of a URL, and
    yes, they make the URL dynamic.  So that means we have two issues
    to consider: static URLs and dynamic URLs.



    A static URL is generally just a URL, not including CGI arguments,
    which will be used to access a page.  There is no significant
    difference between using the url http://localhost/admin  and the
    url htt://localhost/admin=1234 .  In both cases, the theory is the
    same: it's just a piece of information. 



    There are two implementations I can think of for this.  The first
    implementation would be where all administrators connect to the same
    URL.  This implementation has some serious shortcomings. 
    First, the URL is not a secret.



    Now, this might not be completely obvious, but there are some good
    reasons that it's not secret.  First, the URL will display in the
    user's browser.  This lets anyone who walks by see how to connect
    to the admin site.  Second, the URL is passed in the clear to the
    web server, so anyone on the network between your machine and the web
    server can see the administrative URL.



    As I mentioned before, using SSL won't save you, since the URL is
    still passed in the clear (it's not encrypted) when you use SSL.



    Now, when I said that it won't change, I was thinking more of this
    first implementation.  Imagine if you have 100 administrators - or
    even 10,000 admins (I have worked with a few companies that are of this
    size).  Imagine if they all connect to http://localhost/admin, but
    you want to change the URL.  You now make it
    http://localhost/newAdmin.  You have to tell all those
    adminsitrators about what happened. 



    That means that you have to brodcast the new URL to all the
    administrators.  Maybe you do it via email, or maybe via snail
    mail, but you still have to get it out there.  Then, when you shut
    down http://localhost/admin, you'll still have some (possibly
    significant) portion of admins who call for help to connect to the new
    URL.  So, you're stuck having IT tell everyone who calls to use
    the new URL (or possibly point them to the mail, or whatever - this
    becomes a process issue, to make sure only people who should have the
    new URL get it when they call for support, and it's out of scope, here,
    other than to point out that it's a pretty big issue).





    As for the second implementation, you could be passing the URL as
    though
    it were a CGI parameter, but not really (since it's not really a CGI parameter). For example, 
    http://localhost/admin+user=1234.  In this case, you've got one
    page per administrator - which is a whole heck of a lot to maintain
    (yes, you could be using a server side application to do it, and all
    URLs could be intercepted, but that really falls into using it as a CGI
    parameter, which I'll discuss, later).



    Now, you are right: in this case, it's much easier to change
    http://localhost/admin+user=1234 to
    htt://localhost/admin+user=7777.  But you're still stuck with the
    big probelm you had with the first implementation - the URL is not
    secret.



    These two implementations are what I usually think of when I hear "static URL".




    Then there's using dynamic URLs, which means using CGI arguments.  This gets closer to the
    better accepted solution, but it's not quite there, yet.  If you
    change the url to use the admin program, insetad of pointing to some
    static admin page, you probably use a url like
    http://localhost/admin?user=1234.  This is far easier to change
    than the static URL implementation, described above.  In this
    case, you just keep track of the userids (possibly in a flat file or in
    a database), allowing access to anyone who can supply a valid
    userid.  But you're' still stuck with the problem of the URL not
    being secret.  This, however, can be helped.



    If you move the arguments out of the URL and into a form, you start
    using an HTTP POST, instead of an HTTP GET.  I have to explain the
    difference between the two to be sure this is clear.



    In an HTTP GET (the static URLs, and the CGI with the parameters in the
    URL), the browser basically says to the web server, "Hello. 
    Please give me <URL>.  Oh, and here's my cookies.".



    In HTTP POST, the web browser basically says, "Hello.  Please give
    me <URL>.  Oh, and here's the post data, and my cookies."



    By moving from a GET to a POST, you move the data out of the URL, and
    into the request contents.  So, you might say to me, "But atk, you
    haven't resolve the problem you keep harping on - when you POST, isn't
    the data still send in the clear?  Isn't it still public?" 
    And my answer is: this is where SSL is useful.



    When you use SSL, the web server changes its request to the web
    server.  Instead of the requests described above, you get the
    following:



    GET: "Hello.  Please give me <URL>. DSLFJPOFG&OIP#QJH:."

    POST: "Hello.  Please give me <URL>. &YB(!()G
    YIH@!"



    Note that the garbage is intended to demonstrate encrypted data (and
    it's just random garbage from punching random keys on my keyboard, not
    real encrypted data).



    This is much closer to the standard solution (well, a good standard
    solution - I'm not sure that enough companies that require
    authentications do this properly to really consider it a
    standard).  You still have to worry about issues like browser
    cache, actual server implementation, and viewing the web page source,
    but that's all out of scope of this post.



    You: I would not say admin=34710 is guessable...



    Me: Well, you have to consider who might be doing the guessing. 
    The first possibility is an application that is just trying every
    possible URL in search for any valid admin url.  Trying every
    possibilty is referred to as a Brute Force attack.



    It's pretty trivial to implement a program that would connect to your
    machine and try every possible string (first a, then b, then c,
    eventually aa, ab, ac, and eventually admina, adminb, adminc, leading
    to admin=, admin=a, admin=b, admin=b, admin=1).  This will
    probably take a long period of time, but it will eventually result in a
    hit.



    Of course, brute force attacks are garunteed to eventually result in
    a match.  The issue becomes how much time before it finds a
    match.  This would depend upon how many concurrent connections the
    attacker can make, how fast your machine is, and how quickly your
    administrator notices the attack.  Suffice it to say that a
    shorter URL will be brute forced much faster than a longer URL.



    Now, if we assume that you change your URLs so that they're N
    characters wide instead of just 10, for a large enough N that, on
    average, it will take longer to brute force the URL than the standard
    time between URL changes, youi've got a moving target that will be hard
    to hit, and you may just make a brute force attack mathematically
    infeasible.



    But you still aren't safe.  As mentioned above, the URL is still
    public.  And, you've still got a guessing problem!  In this
    case, though, you've got the problem that one admin can guess another
    admin's url (and it's generally considered bad for one administrator to
    be able to masquerade as another administrator).  For example, if
    one adminstrator connects with http://localhost/admin=1234, they can
    easily guess that someone else will connect with
    http://localhost/admin=1233, or http://localhost/admin=5555



    The brute force problem, for one administrator to masquerade as another
    becomes a simple problem - unless you make the number very very large,
    just like the whole URL used to be very very large (thereby lengthening
    the whole URL).



    And with a very very large URL, you have to worry about browsers and
    web servers, and web server applications that can't handle very large
    data.


    The real solution is to use a HTTP POST (a form) with SSL, and strong authentication.





    Back to the three categories: with this URL, you're using Something You
    Have.  It's something written down (nobody's going to remember the
    URL in their head, especially if you make it really really big), and it
    has all the penalties mentioned before.  But, since it's
    electronic, it doesn't get the benifit of being easy to notice when
    stolen - it's pretty easy to copy.  Since it's the URL, it doesn't
    get the benifit of being private - URLs are public (as mentioned above,
    this is true even if you don't want them to be).







    You: But thank you very much for reposting.







    Me: My pleasure.







    You: To what category would things like locking account on three wrong
    guesses fall? I'm not it, I don't have it and, it's not something only
    i know. Are there any external categories to complement the usual three?





    Me: Well, that's not really the point of the categories I mentioned.  The
    three categories are a way to identify things that you authenticate
    with, not how they're handled on the server.  As a rule of thumb,
    if you can't equate the concept with a password, credit card, or finger print, it's probably not one of the three categories.



    What your considering is implementation (and often configuration)
    specific, and it's really in a pair of field sometimes called Intrusion
    Detection and Response (this can also be split into Intrusion Detection
    as one field, and Response as another field).  There are plenty of
    other niche realms that have to do with security.  I would again
    recommend checking out http://www.securityfocus.com, and browsing
    through their tools.  They used to list tools by what... um...
    categories they're useful for.  But keep in mind that the three
    "Something You..." categories are really sub-categories of
    Authentication.



    Intrusion Detection refers to detecting that either an intrusion has
    happened, or that someone is attacking your system and trying to
    intrude.  Noticing that many attempts have been made to
    authenticate with a particular account, and that the number is higher
    than whatever number is acceptable is Intrusion Detection.  You're
    detecting the possibility that someone is trying to authenticate as a
    particular user, but doesn't seem to have the appropriate key
    (password, token, fingerprint).



    The Response, in your example, is to lock the account (in many systems
    this is done for a limited period of time).  In other systems
    (Unix terminal logins) you have what's called an exponential
    backoff.  This means that, every time a failed login attempt is
    made over a particular session, the session will be paused for twice
    the amount of time it was paused for, before.  So, if you fail to
    authenticate once, you might wait 0.25 seconds.  The second try,
    it would be 0.50 seconds.  The third try, 1 second.  After 8
    more tries, you'd be onto 128 seconds - or two minutes between auth
    attemts.  After the 16th try, you'd be at 65,536 seconds (which is
    about 1090 mninutes, which is about 18 hours, if my math is right).



    The response can be anything - including such strange ideas as
    attacking the attacker (which is not recommended), or letting the
    attacker into a false system (known as a honeypot) where s/he things
    s/he has access to good stuff, but really doesn't.






  • Thanks, I'm bookmarking you for future security questions :).



  • Ah yes.

    The secret is out.

    Obscurity has been breached.



  • According to this site and this site and this site it appears that, in fact, the query string is encrypted as part of an SSL session. So the only place the URL appears in plaintext is on the server and on the client. Packets "on the wire" only contain enough plaintext for proper routing.



  • nonDev: Thanks, I'm bookmarking you for future security questions :).


    Me: I'm flattered :)  I don't check this site all that often,
    though, so you might not be able to get a hold of me that easily. 
    Also, there are plenty of people out there that are far better than I
    am.  Again, SecurityFocus is always a great start.



  • GalacticCowboy: According to this site and this site and this site
    it appears that, in fact, the query string is encrypted as part of an
    SSL session. So the only place the URL appears in plaintext is on the
    server and on the client. Packets "on the wire" only contain enough
    plaintext for proper routing.



    Me: Could you point out on the first two sites where you see
    this?  I could only find it on the third one (MS).  It's not
    that I doubt you (I may well be wrong), but I'd like to read it for
    myself, and I just can't locate it.  In the third site, I only saw
    one line.






  • Site 1:  The last sentence of the paragraph following Figure 1. (directly above the heading "The Protection SSL Offers")

    everything which is transmitted is encrypted, including the data in the query string.

    Site 2:  The gray box that says "What does SSL encrypt?" in bold.

    This question is usually geared toward whether or not the path and query string is encrypted in an HTTPS "get" request (this is where form field responses or program variables are tagged on to the end of the url). These fields are stripped off of the URL when creating the routing information in the https packaging process by the browser and are included in the encrypted data block.

    The page data (form, text, and query string) are passed in the encrypted block after the encryption methods are determined and the handshake completes.

    (Emphasis mine in both quotes)

     



  • Kurtis,



    Thank you.  It appears my understanding of SSL was flawed.


Log in to reply