Anton, none of this explains why a “guessable” URI is a problem,
assuming proper authentication and authorization is in place to protect
that URI.
Here’s hoping no-one here works for the DHS or companies that are
involved with airport securityI’m semi-hoping that there’s someone here who does, I need a cheap way of
getting to Portland from Australia. Is the cargo hold pressurized? I
don’t
mind sleeping between crates.
–
Ryan B.
Feel free to add me to MSN and/or GTalk as this email.
Way back in this thread when I when I submitted my hashed UUID
suggestion I
fat fingered my keyboard trying to say… some one wanting to do this
was
likely making a design mistake but I posted anyway because there are a
few
legitimate uses.
You want to limit the ability of scripts to navigate your site and
scrape
information.
You want to allow users to provide access to third parties without
having to
authenticate them. The user uploads a resource and gets a big nasty
hashed
id for there resource. They can give it to who ever they want or not.
The
site’s not involved.
On Jan 9, 2008 5:42 PM, Jeremy Weiskotten
[email protected]
wrote:
Anton, none of this explains why a “guessable” URI is a problem,
assuming proper authentication and authorization is in place to protect
that URI.Posted via http://www.ruby-forum.com/.
–
Michael G.
http://blog.michaelgreenly.com
@Michael: good points. There are legitimate uses for UUIDs (hashes
aren’t good identifiers because they can collide). As long as people
don’t consider it a security feature…
you can override the to_param method in the model and change what you
want.
More info to visit http://www.railscasts.com/episodes/63.
Jeremy Weiskotten said the following on 09/01/08 06:42 PM:
Anton, none of this explains why a “guessable” URI is a problem,
assuming proper authentication and authorization is in place to protect
that URI.
- You keep changing my words and hence changing my meaning, so as to
suit your argument.
I never said “guessable”. Guessable" is guessing a password based on
knowing the person, trying his birth date, his SSN, his wedding
anniversary, the name of his wife or first child or … the same one he
uses at a Honeypot “social” site.
I said “predictable”. If the records are assigned sequential numbers
… see my earlier posts. Its not about “obscuring”. its about leaking
information about internal operations that can be used, along with
other information, as leverage.
- Even “proper” authentication & authorization seems to fail.
We’re playing a catch-up game with the hackers. The hard evidence is
that they eventually find flaws or ways round our security measures. If
it were as simple as you make out, some genius programmer could write
the perfect code and all the security people could retire.
Every year I attend a conference where the most popular session is a
security expert showing us the exploits that have been observed by the
monitoring sites and Honeypots against the best of security measures.
Part of the reason we know is that we don’t rely just on the “proper”
code; the Honeypots are wrapped in monitoring tools, logging and packet
trace. That’s the whole point of the Honeypot.
So we code new layers of defences.
Do you sanitize all input (including your params)?
Do you do boundary-value testing?
Do you do combinatorial effect testing or do you just test one thing at
a time?
Most exploits are ones that would probably produce reactions like “Hey
That’s cheating” or “You’re not supposed to do that!” from programmers.
Certainly I’ve had that said to me by programmers and designers when
I’ve demonstrated “off the shelf” attacks against their systems.
And its a moving target.
If you think your authentication and authorization system - or ANY such
for that matter - is infallible then either you’re a genius or a fool.
–
No athlete is crowned but in the sweat of his brow.
Saint Jerome, Letter
The UUID can be predictable and the odds of a collision in the hash will
be
around 1 in the number of keys used divided by 2^160. The planet has
fewer
atoms. I’ll take my chances but if you wanted to play it safe you’d
simply
check for collision and re-roll.
Your more likely to meet the real Yoda tomorrow than have a collision.
Your
more likely to witness Superman and Yoda fight to the death tomorrow
than
have two collisions in a row.
My moneys on the little green guy, jedi mind tricks for the win!
On Jan 9, 2008 7:17 PM, Jeremy Weiskotten
[email protected]
wrote:
@Michael: good points. There are legitimate uses for UUIDs (hashes
aren’t good identifiers because they can collide). As long as people
don’t consider it a security feature…Posted via http://www.ruby-forum.com/.
–
Michael G.
http://blog.michaelgreenly.com
If you think your authentication and authorization system - or ANY such
for that matter - is infallible then either you’re a genius or a fool.
No, it’s not infallible. But it’s necessary and provides a real level of
security. You still haven’t explained (without any strawman arugments)
how “predictable” URIs might be a problem. Using pseudo-random keys
doesn’t increase security in any real away. Leaking the fact that you
use a sequential surrogate key doesn’t give a hacker any useful
knowledge about your system, and using non-predictable keys doesn’t
protect anything.
Here’s another solution to this problem
http://blog.michaelgreenly.com/2008/01/obsificating-ids-in-urls.html
On Jan 6, 2008 9:08 PM, michael greenly [email protected] wrote:
then decrypt it before i use it within the application … this is what i
–
Michael G.
http://blog.michaelgreenly.com
–
Michael G.
http://blog.michaelgreenly.com