i am developing a community which has user profiles ... those are now accessible through an url like e.g. /user/profile/10 the 10 is the id of the user within the database. now i dont really like the plain ID within the url because it is very simple to iterate through the users .. does someone has a nice solution for encrypting and decrypting the id? some simple encryption would be fine -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michal Gabrukiewicz said the following on 06/01/08 04:17 PM:> i am developing a community which has user profiles ... those are now > accessible through an url like e.g. > > /user/profile/10 > > the 10 is the id of the user within the database. now i dont really like > the plain ID within the url because it is very simple to iterate through > the users ..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. -- It''s a well-known fact that the ISO/OSI seven-layer protocol stack actually has two additional layers: Layer 8: finance Layer 9: politics However, there are network gurus who know how to route around them. . . . - Les Bell, RHCE, CISSP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Anton Aylward wrote:> Michal Gabrukiewicz said the following on 06/01/08 04:17 PM: >> i am developing a community which has user profiles ... those are now >> accessible through an url like e.g. >> >> /user/profile/10 >> >> the 10 is the id of the user within the database. now i dont really like >> the plain ID within the url because it is very simple to iterate through >> the users .. > > 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.and do u have a solution? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michal Gabrukiewicz said the following on 06/01/08 05:12 PM:> Anton Aylward wrote: >> Michal Gabrukiewicz said the following on 06/01/08 04:17 PM: >>> i am developing a community which has user profiles ... those are now >>> accessible through an url like e.g. >>> >>> /user/profile/10 >>> >>> the 10 is the id of the user within the database. now i dont really like >>> the plain ID within the url because it is very simple to iterate through >>> the users .. >> 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. > > > and do u have a solution?There are many. Google for security, but you''re on the right idea when you talk about ''encrypt'' the ID. Of course the internal ''find_by_id'' and the external form in the URL can be different. How strong do you want it to be? How meaningful do you want it to be? If users sign up as "Firstname, Lastname" you could make that the ID - CamelWord it to FirstnameLastname and get /user/profile/FirstnameLastname This is ''meaningful''. Its not obscure, but at least its immune to easy "Brute Force"attacks of the form [1 ... 100000000].each { |i| attack.send("/usr/profile/" + i.to_s) } http://en.wikipedia.org/wiki/Brute_force_attack To be really paranoid, you could take sha1hash(firstname.to_s + lastname.to_s) Yes, it would be possible to generate a big list of names, but think about this: firstname.length and lastname.length can vary from 2 to 20 (or whatever) characters. A generator for all that would take a long time to run. An attack like this would show up in your log files and IDS quite clearly. Log files monitoring? IDS? They too are part of security. You can''t just rely on programming. Security is about overlapping checks and controls. But even so, all you''re doing is uppng the ante, and there may be other areas of attack. http://en.wikipedia.org/wiki/Residual_risk -- "The Air Force is reacting to the EPA ban on CFC''s by replacing them in the cooling systems of the ICBMs. If they are ever fired, it will be an environmentally friendly nuclear holocaust, not threatening the Ozone layer." -- _Access to Energy_, July 1993 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 06 Jan 2008, at 23:08, Anton J Aylward 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.1. If you don''t want it to be seen, it should have been in a password protected part of your site. Never trust user input, whether it''s in forms or in urls. 2. If you want to avoid record scraping for data within the pages, use different techniques like clientside decrypting of encrypted elements or use rmagick to render the data as an image instead of a string. 3. If you want to avoid record scraping of entire pages over your complete database or brute force attacks, use log file analyzers that reconfigure your firewall to ban those ips when certain conditions are met. fail2ban is such a solution. 4. If you want to avoid hotlinking to files, use Apache/other webserver techniques to avoid it. 5. If you need to make temporary file downloads with a hash in the url, use a simple named route instead of shoving it in a RESTful route. Believe me, this kind of scraping is the thing you need to worry about the least. Best regards Peter De Berdt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
thanks for the answers guys .. but i am looking for the best solution to encrypt and decrypt the id of my user .. anton i thought about your solution with first and lastname but i could have duplicate names and then its not that straightforward anymore ... i just want to crypt the id so it does not look obvious that you can just grab all of them with bruteforce -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Peter De Berdt said the following on 06/01/08 06:08 PM:>> This kind of scanning is a common ''pre-attack'' scan used by malicious >> >> hackers. >> > > 1. If you don''t want it to be seen, it should have been in a password > protected part of your site. Never trust user input, whether it''s in > forms or in urls.Absolutely. The Post.find( .... params[:post] ...) is high risk. Always sanitise and filter your inputs. The example given in AWDWR about cross-site-scripting is just the beginning.> 2. If you want to avoid record scraping for data within the pages, use > different techniques like clientside decrypting of encrypted elements or > use rmagick to render the data as an image instead of a string.Just as a generation of spammers did to try and get around SpamAssassin. (Only it didn''t work.)> 3. If you want to avoid record scraping of entire pages over your > complete database or brute force attacks, use log file analyzers that > reconfigure your firewall to ban those ips when certain conditions are > met. fail2ban is such a solution.Log file analysis and IDS/IPS are an essential part of a security strategy.> 4. If you want to avoid hotlinking to files, use Apache/other webserver > techniques to avoid it.Again, well documented.> 5. If you need to make temporary file downloads with a hash in the url, > use a simple named route instead of shoving it in a RESTful route.LOL! And yes, lots of sites use temporary URL strings with limited lifetimes. Its no different from fixed lifetime values in the cookies.> Believe me, this kind of scraping is the thing you need to worry about > the least.... until you get bitten. The cost of retrofitting security after an incident is always going to be greater than the cost of addressing the risks when designing the system. You don''t always have to load up the complete suite of security tools from the start, but do think about it. Sometimes small architectural changes that don''t really affect the code development can make a big positive or negative impact on security. Sometimes it IS coding style. For example, I list the real actions in controllers with ''public ....'' and use ''hide_action''. But then I''m a bit paranoid. (Actually I''m paid to be paranoid.) There is a great deal of information on secure programming style and considerations. Some is language specific and some is perfectly general. Some that seems specific because of the examples is actually quite general. (injection attacks, XSS, print format string hijacking ...) http://www.securecoding.org/companion/links.php Consider also that the term ''security'' means more than keeping hackers and attacks out. You may have a requirement for availability and for protecting PII or maintaining integrity of records. To say nothing of ''resilience and robustness'', for example ensuring availability to legitimate users in the faces of DoS attack. See also http://rubythis.blogspot.com/2006/11/rails-security-checklist.html http://nob.cs.ucdavis.edu/bishop/papers/2006-cisse-2/clinic.pdf http://press.oreilly.com/pub/pr/1388 Rubyists can always learn from Perl - one way or another :-) -- Try to learn something about everything and everything about something. Thomas H. Huxley --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michal Gabrukiewicz said the following on 06/01/08 07:27 PM:> thanks for the answers guys .. but i am looking for the best solution to > encrypt and decrypt the id of my user .. > > anton i thought about your solution with first and lastname but i could > have duplicate names and then its not that straightforward anymore ...I use this on my Wiki. Dealing with ''duplicates'' is straight forward if you think about it. There are many possible solutions. What I do is prompt for first and last name and then use javascript to join them and check to see if that already exists. If it does I add a digit and try again. The result is offered as a suggestion, the user can change it and "submit", but that might still be a duplicate, so he gees told and we go round again. Luckily I have a pretty unique name, but at some sites I''m "anton1" or even "anton7" But the important thing is defending against Brute Force and predictable sequence attacks. As I said, the basic id# approach of AWDWR is a CFM. -- Growth for the sake of growth is the ideology of the cancer cell. - Edward Abbey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Perhaps you could add salt to this, such as their user id? Encrypt their first name, last name AND id to ensure a different result from everyone else? On Jan 7, 2008 12:18 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> wrote:> > Michal Gabrukiewicz said the following on 06/01/08 07:27 PM: > > thanks for the answers guys .. but i am looking for the best solution to > > encrypt and decrypt the id of my user .. > > > > anton i thought about your solution with first and lastname but i could > > have duplicate names and then its not that straightforward anymore ... > > I use this on my Wiki. Dealing with ''duplicates'' is straight forward if > you think about it. There are many possible solutions. > > What I do is prompt for first and last name and then use javascript to > join them and check to see if that already exists. If it does I add a > digit and try again. The result is offered as a suggestion, the user > can change it and "submit", but that might still be a duplicate, so he > gees told and we go round again. > > Luckily I have a pretty unique name, but at some sites I''m "anton1" or > even "anton7" > > But the important thing is defending against Brute Force and predictable > sequence attacks. As I said, the basic id# approach of AWDWR is a CFM. > -- > Growth for the sake of growth is the ideology of the cancer cell. > - Edward Abbey > > > >-- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
cant i just take the id and encrypt it using a key (chosen by me) and then decrypt it before i use it within the application .. this is what i would like to achive ... i dont want to hash the values because then i cannot really use it within my queries.. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Perhaps change the URL to something like 10-michal-gabrukiewicz, or even just michal-gabrukiewicz. When a user changes their first and last names, save this as another field in the table as that (michal-gabukiewicz) and then do a find by that field. On Jan 7, 2008 1:16 PM, Michal Gabrukiewicz < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > cant i just take the id and encrypt it using a key (chosen by me) and > then decrypt it before i use it within the application .. this is what i > would like to achive ... > i dont want to hash the values because then i cannot really use it > within my queries.. > -- > Posted via http://www.ruby-forum.com/. > > > >-- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan Bigg wrote:> Perhaps change the URL to something like 10-michal-gabrukiewicz, or even > just michal-gabrukiewicz. When a user changes their first and last > names, > save this as another field in the table as that (michal-gabukiewicz) and > then do a find by that field. >that sounds good but then i need to maintain another db field ... is there no way for simple encryption? it would be okay for me to have profile urls like this /user/4fh39dj3jd> On Jan 7, 2008 1:16 PM, Michal Gabrukiewicz < > rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > >> > -- > Ryan Bigg > http://www.frozenplague.net > Feel free to add me to MSN and/or GTalk as this email.-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Simple encryption is harder than Just One More Field (tm) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
It would seem to me that if you think you need to obfuscate the id value in
the url there''s likely a but instead of getting into that I''ll
offer a
possible solution.
require ''uuidtools''
class Post < ActiveRecord::Base
def before_create()
self.id = OpenSSL::Digest.SHA1.hexdigest(UUID.timestamp_create())
end
end
This should be a drop in replacement and make it impossible to predict id
values...
On Jan 6, 2008 8:46 PM, Michal Gabrukiewicz <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>
> cant i just take the id and encrypt it using a key (chosen by me) and
> then decrypt it before i use it within the application .. this is what i
> would like to achive ...
> i dont want to hash the values because then i cannot really use it
> within my queries..
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--
Michael Greenly
http://blog.michaelgreenly.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Michael Greenly wrote:> It would seem to me that if you think you need to obfuscate the id value > in > the url there''s likely a but instead of getting into that I''ll offer a > possible solution. > > require ''uuidtools'' > class Post < ActiveRecord::Base > def before_create() > self.id = OpenSSL::Digest.SHA1.hexdigest(UUID.timestamp_create()) > end > endyeah but then i loose my id .. i dont want it to be extremely secure .. a simple xor encryption should be fine i think .. does someone has it in the pocket? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Is not firstname-lastname secure enough? On Jan 7, 2008 1:44 PM, Michal Gabrukiewicz < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Michael Greenly wrote: > > It would seem to me that if you think you need to obfuscate the id value > > in > > the url there''s likely a but instead of getting into that I''ll offer a > > possible solution. > > > > require ''uuidtools'' > > class Post < ActiveRecord::Base > > def before_create() > > self.id = OpenSSL::Digest.SHA1.hexdigest(UUID.timestamp_create()) > > end > > end > > yeah but then i loose my id .. i dont want it to be extremely secure .. > a simple xor encryption should be fine i think .. does someone has it in > the pocket? > > -- > Posted via http://www.ruby-forum.com/. > > > >-- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
then id-firstname-lastname On Jan 7, 2008 2:14 PM, Michal Gabrukiewicz < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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 > -- > Posted via http://www.ruby-forum.com/. > > > >-- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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... -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Quoting Michal Gabrukiewicz <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>:> > i am developing a community which has user profiles ... those are now > accessible through an url like e.g. > > /user/profile/10 > > the 10 is the id of the user within the database. now i dont really like > the plain ID within the url because it is very simple to iterate through > the users .. >How about restricting user profile so only a user and the admin can view a profile? Jeffrey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <ror-NvlhjL+mh2pvqUDvg8NhqHL8HoS0Hn3T@public.gmane.org> wrote:> > Quoting Michal Gabrukiewicz <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>: > > > > i am developing a community which has user profiles ... those are now > > accessible through an url like e.g. > > > > /user/profile/10 > > > > the 10 is the id of the user within the database. now i dont really like > > the plain ID within the url because it is very simple to iterate through > > the users .. > > > How about restricting user profile so only a user and the admin can view a > profile? > > Jeffrey > > > >-- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Quoting Ryan Bigg <radarlistener-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 duplicatesDuplicates 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Indeed in nothing is the power of the Dark Lord 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_ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008 4:08 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Graff wrote:> On Jan 6, 2008 4:08 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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. > > --MichaelAbsolutely 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Graff said the following on 09/01/08 03:12 PM:> On Jan 6, 2008 4:08 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 9, 2008 2:33 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 CarsonPredictability 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jeremy Weiskotten said the following on 09/01/08 03:27 PM:> Michael Graff wrote: >> On Jan 6, 2008 4:08 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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. -- If you would thoroughly know anything, teach it to others. Tryon Edwards (1809 - 1894) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Anton Aylward 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 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 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 9, 2008 2:42 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Over himself, over his own body and mind, the individual is sovereign. --John Stuart Mill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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? ;) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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." - Theodor W. Adorno --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. http://itivarden.idg.se/2.2898/1.139405 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. http://news.bbc.co.uk/1/hi/entertainment/7174760.stm 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". -- The master worries about the work, and the apprentice worries about the tools. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > 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 ofgetting to Portland from Australia. Is the cargo hold pressurized? I don''t mind sleeping between crates. -- Ryan Bigg http://www.frozenplague.net Feel free to add me to MSN and/or GTalk as this email. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 Greenly http://blog.michaelgreenly.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
@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/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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.1. 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. 2. 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 Greenly http://blog.michaelgreenly.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <mgreenly-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> It would seem to me that if you think you need to obfuscate the id value > in the url there''s likely a but instead of getting into that I''ll offer a > possible solution. > > require ''uuidtools'' > class Post < ActiveRecord::Base > def before_create() > self.id = OpenSSL::Digest.SHA1.hexdigest(UUID.timestamp_create()) > end > end > > This should be a drop in replacement and make it impossible to predict id > values... > > > > On Jan 6, 2008 8:46 PM, Michal Gabrukiewicz < > rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > > > cant i just take the id and encrypt it using a key (chosen by me) and > > then decrypt it before i use it within the application .. this is what i > > would like to achive ... > > i dont want to hash the values because then i cannot really use it > > within my queries.. > > -- > > Posted via http://www.ruby-forum.com/. > > > > > > > > > > > -- > Michael Greenly > http://blog.michaelgreenly.com-- Michael Greenly http://blog.michaelgreenly.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---