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.
Quoting Ryan Bigg <radarlistener@gmail.com>:
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 Gabrukiewicz said the following on 06/01/08 10:44 PM:
Ryan Bigg 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.
Michal Gabrukiewicz said the following on 06/01/08 10:53 PM:
Ryan Bigg 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.
Anton Aylward 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
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 Graff 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.
Michael Graff said the following on 09/01/08 03:12 PM:
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.
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.
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
Anton Aylward wrote:
Michael Graff 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:
Michael Graff 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.
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.
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 Graff 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.
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.
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 Bigg 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 Bigg said the following on 09/01/08 06:13 PM:
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.
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.
http://www.canlii.org/en/on/onsc/doc/2007/2007canlii54665/2007canlii54665.html 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".
Anton, none of this explains why a "guessable" URI is a problem, assuming proper authentication and authorization is in place to protect that URI.
Jeremy Weiskotten said the following on 09/01/08 06:31 PM:
Ryan Bigg 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.
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.
Here’s hoping no-one here works for the DHS or companies that are
involved with airport security
I’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.