Then what’s the point of the user having the profile in the first place?
A
profile is a way for people to see everything about a specific user.
On Jan 7, 2008 3:53 PM, Jeffrey L. Taylor [email protected]
wrote:
the users …
How about restricting user profile so only a user and the admin can view a
profile?Jeffrey
–
Ryan B.
Feel free to add me to MSN and/or GTalk as this email.
Quoting Ryan B. [email protected]:
Then what’s the point of the user having the profile in the first place? A
profile is a way for people to see everything about a specific user.
I was thinking of a user profile as the user’s preferences, password,
etc.
Michal G. said the following on 06/01/08 10:44 PM:
Ryan B. wrote:
Is not firstname-lastname secure enough?
yep it is and i would really prefer this … but my problem is that i
have duplicates
Duplicates aren’t a problem.
A number of ways round that have been suggested.
And don’t forget, any hash or XOR of a duplicate is still a collision.
That’s why some forms of hashing use salt.
–
Enter any 11-digit prime number to continue.
Michal G. said the following on 06/01/08 10:53 PM:
Ryan B. wrote:
then id-firstname-lastname
damn you are right … this was mentioned already before but i didnt
recognized that this combination is okay … when i saw the id i
immediately thought this is wrong… but it works like this! thanks…
A closing note:
You idea of keys that are hashes like
/user/4fh39dj3jd
has the advantage over
/user/10-michal-gabrukiewicz
in that it doesn’t leak names or the underlying ID# that might be used
elsewhere in the application.
How paranoid do you need to be? If this were an e-commerce application
and I were auditing it (my day job) I’d give failing marks. PCI,
BASEL-2 and others require that any such PII not be leaked. Having a
pattern in the URL that gives away a means whereby hackers could gain
leverage (and possibly with other information and step by step penetrate
or Dos) is explicitly excluded.
American banks are a bit slacker than European and Scandinavian banks
because they work out their risk/loss figures differently.
–
Indeed in nothing is the power of the Dark L. more clearly shown than
in the estrangement that divides all those who still oppose him.
–J. R. R. Tolkien (as Haldir the elf), The Fellowship of the Ring
Anton A. wrote:
A closing note:
You idea of keys that are hashes like
/user/4fh39dj3jd
has the advantage over
/user/10-michal-gabrukiewicz
in that it doesn’t leak names or the underlying ID# that might be used
elsewhere in the application.How paranoid do you need to be? If this were an e-commerce application
and I were auditing it (my day job) I’d give failing marks. PCI,
BASEL-2 and others require that any such PII not be leaked. Having a
pattern in the URL that gives away a means whereby hackers could gain
leverage (and possibly with other information and step by step penetrate
or Dos) is explicitly excluded.American banks are a bit slacker than European and Scandinavian banks
because they work out their risk/loss figures differently.
yep you are completely right … that was also my first intention but
for my community its not that bad to show the id … at least now not
… it would be completely different for enterprise apps
thanks all for your contribution…
by the way i installed the permalink_fu plugin which helped me to
generate the permalink using a composite of id-firstname-lastname
On Jan 6, 2008 4:08 PM, Anton J Aylward [email protected] wrote:
Yes, this is an intrinsic security flaw that appears in much of Rails:
http://example.com/web/84/topic/12379
A simple loop can find out all the projects, all the topics.
This kind of scanning is a common ‘pre-attack’ scan used by malicious
hackers.
What encrypting the ID does is called “security by obscurity” and is
in fact not security, but the illusion of security. If you treat
knowing the ID as part of the security of an object, then you have
already lost.
–Michael
Michael G. wrote:
On Jan 6, 2008 4:08 PM, Anton J Aylward [email protected] wrote:
Yes, this is an intrinsic security flaw that appears in much of Rails:
http://example.com/web/84/topic/12379
A simple loop can find out all the projects, all the topics.
This kind of scanning is a common ‘pre-attack’ scan used by malicious
hackers.What encrypting the ID does is called “security by obscurity” and is
in fact not security, but the illusion of security. If you treat
knowing the ID as part of the security of an object, then you have
already lost.–Michael
Absolutely right. I’m surprised it took this long for anyone to point
this out.
What you really need is authorization. Even if someone guesses (or gets
their hands on) a valid URI, you should verify that they’re authorized
to access that resource if it needs to be protected. Otherwise you’re
just crossing your fingers, closing your eyes, and doing the ostrich
head in sand thing.
On Jan 9, 2008 2:33 PM, Anton J Aylward [email protected] wrote:
And the point isn’t just obscuring. Security isn’t “just one thing”.
You’re not going to secure your system by having obscured IDs. You’re
going to have an IDS/IPS and be monitoring your logs for the huge number
of failed attempts.As I said, that kind of scanning is a warning sign of an attack.
After such a scan, the next attack will be to try to break in. If
that break in is possible then your security is weak, or the attacker
has other knowledge that makes the attack possible.
If your site is used, and popular, you will end up with links to many
parts of the site. You might even cross-link “if you like this
forum…” items. Who knows.
I would rather spend time on actual security rather than the illusion of
such.
–Michael
Michael G. said the following on 09/01/08 03:12 PM:
What encrypting the ID does is called “security by obscurity” and is
in fact not security, but the illusion of security. If you treat
knowing the ID as part of the security of an object, then you have
already lost.
The illusion of security is a looser, yes, but this isn’t simply
obscuring it.
Part of the toolkit the famous hacker Kevin Mitnick used was being able
to predict TCP sequence numbers on old-design stacks. More modern
stacks now used a PRNG so the sequence isn’t predictable.
A design where
[ …, n-2, n-1, n, n+1, n+2 …]
are valid for n < last created record is predictable.
Yes, the modern stacks could be defeated, but there would be a lot of
wasted attempts for invalid numbers.
And the point isn’t just obscuring. Security isn’t “just one thing”.
You’re not going to secure your system by having obscured IDs. You’re
going to have an IDS/IPS and be monitoring your logs for the huge number
of failed attempts.
As I said, that kind of scanning is a warning sign of an attack.
–
Television – the longest amateur night in history.
– Robert Carson
Anton A. wrote:
Michael G. said the following on 09/01/08 03:12 PM:
What encrypting the ID does is called “security by obscurity” and is
in fact not security, but the illusion of security. If you treat
knowing the ID as part of the security of an object, then you have
already lost.The illusion of security is a looser, yes, but this isn’t simply
obscuring it.Part of the toolkit the famous hacker Kevin Mitnick used was being able
to predict TCP sequence numbers on old-design stacks. More modern
stacks now used a PRNG so the sequence isn’t predictable.A design where
[ …, n-2, n-1, n, n+1, n+2 …]
are valid for n < last created record is predictable.Yes, the modern stacks could be defeated, but there would be a lot of
wasted attempts for invalid numbers.And the point isn’t just obscuring. Security isn’t “just one thing”.
You’re not going to secure your system by having obscured IDs. You’re
going to have an IDS/IPS and be monitoring your logs for the huge number
of failed attempts.As I said, that kind of scanning is a warning sign of an attack.
–
Television – the longest amateur night in history.
– Robert Carson
Predictability is not necessarily a security hole. Unless an
unauthorized person has access to secure or private data, there’s no
security hole. Being able to guess that if there’s a person with ID 25
that there’s probably a person with ID 24 and another with 26 doesn’t
mean that I’ll be able to see their data. The application should protect
those resources if they need to be protected.
Chances are the URIs will be discoverable anyway. If there are any links
to them (and there most likely will be) a simple scraping spider will
hit them.
Jeremy Weiskotten said the following on 09/01/08 03:27 PM:
What encrypting the ID does is called “security by obscurity” and is
their hands on) a valid URI, you should verify that they’re authorized
to access that resource if it needs to be protected. Otherwise you’re
just crossing your fingers, closing your eyes, and doing the ostrich
head in sand thing.
Oh dear.
Why do you think hackers would stop at using just one technique?
They never have in the past.
So why would you use just one protection scheme.
Why do you think that any one protection scheme will be adequate?
It never has been in the past
Why do you think that there will never be bugs in the code?
Do I really have to explain?
Why do you think that complex systems won’t have unexpected properties
that could be exploited?
Complex systems have always shown this to be the case
And why do you want to create systems where valid URLs are predictable
on the basis of other URLs?
Take some time out to study a few of the many, many techniques that
hackers use to gain access even when there are authorization schemes in
place.
–
If you would thoroughly know anything, teach it to others.
Tryon Edwards (1809 - 1894)
Anton A. wrote:
Oh dear.
Why do you think hackers would stop at using just one technique?
They never have in the past.
So why would you use just one protection scheme.
Why do you think that any one protection scheme will be adequate?
It never has been in the past
Why do you think that there will never be bugs in the code?
Do I really have to explain?
Why do you think that complex systems won’t have unexpected properties
that could be exploited?
Complex systems have always shown this to be the caseAnd why do you want to create systems where valid URLs are predictable
on the basis of other URLs?Take some time out to study a few of the many, many techniques that
hackers use to gain access even when there are authorization schemes in
place.
If the resource is protected with simple authorization, why “encrypt”
(obscure) the ID? If I lock my door with a deadbolt, there’s no need to
cover my door with a tarp to hide it.
Using non-guessable URIs does not help you once a URI is discovered, and
provides a false sense of security. It’s better to make it truly secure
in the first place, and not bother with the imaginary stuff.
On Jan 9, 2008 2:42 PM, Anton J Aylward [email protected] wrote:
Why do you think hackers would stop at using just one technique?
They won’t. But if keeping someone from knocking on the door is the
strategy you want to spend time on, go for it.
And why do you want to create systems where valid URLs are predictable
on the basis of other URLs?
I don’t want to. I just don’t care about that aspect of security when
there are so many other places to focus on that, IMHO, yield good
results.
Take some time out to study a few of the many, many techniques that
hackers use to gain access even when there are authorization schemes in
place.
I deal with security all the time. I am one of the authors of BIND 9,
which is in use in more places than Rails. 
And yes, in the DNS world there are cases where you want to keep
things unguessable (query IDs) but since it is a small little 16-bit
number, it’s hard. It is also the only security field that is really
there for this purpose.
However, in the web world, you have many, many more options than
security by obscurity. I suggest people focus on those rather than
hiding IDs.
–Michael
Michael G. said the following on 09/01/08 04:01 PM:
[…]
I deal with security all the time. I am one of the authors of BIND 9,
which is in use in more places than Rails.
And yes, in the DNS world there are cases where you want to keep
things unguessable (query IDs) but since it is a small little 16-bit
number, it’s hard. It is also the only security field that is really
there for this purpose.
No, its not about "unguessbility’ its about not being predictable.
unpredictability is used in TCP sequencing to prevent hijacking of
sessions. Its also used in various forms in protocols like BGP to
prevent or damp oscillations, so it has uses outside of
“authentication”.
However, in the web world, you have many, many more options than
security by obscurity. I suggest people focus on those rather than
hiding IDs.
As I said, its not about obscurity, its about predictability.
And overlapping controls.
–
Over himself, over his own body and mind, the individual is sovereign.
–John Stuart Mill
Anton, let me guess… you’re one of those who believes that exposing
someone’s user name is a security hole, even if there’s a password. Am I
right? 
Jeremy Weiskotten said the following on 09/01/08 04:39 PM:
Anton, let me guess… you’re one of those who believes that exposing
someone’s user name is a security hole, even if there’s a password. Am I
right?
No. That has nothing to do with what we’re discussing.
You’re hung up on ‘obscuring’ when I’m talking about predictability.
If you go back though this thread and read my other postings you’ll see
that while did answer the original question about encrypting the id, I
also suggested using names instead of ID.
Which fits in with my point about predictability rather than obscurity.
Example, linking back to the beginning of this thread:
Knowing that the URL
/user/9
exists tells you that /user/1…8 are there and probably /user/10
onwards.
And its easy to check. That’s what I mean about predictability.
But knowing
/user/JeremyWeiskotten
doesn’t tell you about the existence of any other records.
That’s not obscurity, its about predictability.
Its not obscured anything. The hacker may try assuming that the
FirstnameLastname is the only format, but that need not be true. On
one site I run the registration suggests an ID based on the Firstname
Lastname, but the user can override it. And this is independent of the
response to the login prompt. Which they can choose as well. And all
this is independent of the e-mail address they use.
The user name need not be the ID handed for the login sequence.
In fact there is no reason why that should be public information
http://www.vaporbase.com/postings/Login_with_your_email_address
See also “The White Night’s Song” in Alice.
What a thing is, what its name is, what its title is and what its called
need not be the same.
Yes, I know this thread started with the request for encrypting the ID.
But go back and look: I tried saying that user a ‘name’ was a good
technique early on.
From a business POV, the names are more meaningful, they are something
that the end user can see “makes sense” and feels less intimidating than
an awkward alphanumeric string generated by SHA1.
Security has many facets and the code is just one of them.
From a business POV, issues like PCI, SOX, HIPPA, COSO, PIPEDA and other
legal and regulatory requirements are drivers of policy and determine if
and why someone may be granted or revoked an account, and the business
processes that work that may be more important than the details we are
discussing.
–
“Intolerance of ambiguity is the mark of an authoritarian personality.”
This kind of talk reminds me of the piracy wars going on. Big companies
spend millions of dollars trying to figure out some latest piece of
technology so people can’t pirate The Next Big Thing.
The Next Big Thing is released, and within a few days it’s protection is
shattered and The Next Big Thing is free for everybody.
The time you spend on security will be wasted by someone who’s dedicated
enough to get at your data. You want an equal balance between usability
and
security, but don’t go to either extreme or your site will be hacked
easily
or nobody will want to use it.
Ryan B. wrote:
This kind of talk reminds me of the piracy wars going on. Big companies
spend millions of dollars trying to figure out some latest piece of
technology so people can’t pirate The Next Big Thing.The Next Big Thing is released, and within a few days it’s protection is
shattered and The Next Big Thing is free for everybody.The time you spend on security will be wasted by someone who’s dedicated
enough to get at your data. You want an equal balance between usability
and
security, but don’t go to either extreme or your site will be hacked
easily
or nobody will want to use it.
Good point. If someone wants it bad enough, they’ll probably get it
eventually. That doesn’t mean we shouldn’t be security-conscious and
take appropriate precautions, but we shouldn’t waste time on
pseudo-security that doesn’t actually protect anything.
Ryan B. said the following on 09/01/08 06:13 PM:
easily or nobody will want to use it.
Indeed.
And its why the code in the application is only part of the security
profile.
Legal, HR, InfoSec, Audit, all have their roles as well.
Loss of service, privacy, function … can result from many things apart
from code issues.
A university hospital in Sweden lost power. Backup power worked just
fine. Cooling systems for the server hall weren’t on backup power, so
three hours later, the servers overheated and had to shut down. The
EHR systems went off-line.
Stupidity.
Abuse of NDA and IP
And of course disclosure of confidential information by mis-handling of
records, as we’ve seen recently in the UK.
All this affects the business (i.e. people who pay us) even though it
has nothing to do with the code.
But that doesn’t mean you can be lax.
The attacker only needs one ‘hole’; the defender has to mount a defence
on all fronts.
And the attacker probably has a lot more ingenuity, persistence,
resources and bloody-minded-ness than all of us put together and cares
nothing about “collateral damage”.
–
The master worries about the work, and the apprentice worries about the
tools.
Jeremy Weiskotten said the following on 09/01/08 06:31 PM:
and
security, but don’t go to either extreme or your site will be hacked
easily
or nobody will want to use it.Good point. If someone wants it bad enough, they’ll probably get it
eventually. That doesn’t mean we shouldn’t be security-conscious and
take appropriate precautions, but we shouldn’t waste time on
pseudo-security that doesn’t actually protect anything.
Here’s hoping no-one here works for the DHS or companies that are
involved with airport security
But don’t forget, there are other things a business might want to
protect. Enron and WorldCom weren’t taken down because they had poor
InfoSec on their web site, and wouldn’t have survived if their web site
had more features.
Sometimes you just have to do what the Powers That Be tell you to get on
with even if it doesn’t make sense at the level you an see. Sometimes
you’re just an important part of a bigger system and what makes you
important is that you do what is required of you.
–
It is the first step of wisdom to recognize that the major advances in
civilization are processes which all but wreck the society in which they
occur.
–Alfred North Whitehead
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs