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).
- as long as nobody knows that you exist. But as soon as anyone
-
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.
-
-
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(!()GYIH@!"
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.