House of Fusion
Search over 2,500 ColdFusion resources here
  
Home of the ColdFusion Community

Mailing Lists
Home /  Groups /  ColdFusion Talk (CF-Talk)

User Name/Password Concepts

  << Previous Post |  RSS |  Sort Oldest First |  Sort Latest First |  Subscribe to this Group Next >> 
Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Ian Skinner
12/30/2002 06:01 PM

I am writing a User ID/Password login in for a commercial, registered members only type, Internet site.  Not adult orientated if you care *S*.   I've written simple CF Login functions before, but this current project that is going to require a little more true security then I've dealt with before. I'm asking all the guru's and other experienced CF developers if you can help with some ideas.  Basically I want to provide a fairly secure site that doesn't turn away potential users/members/customers.   What I'm interested in is comments and ideas on balancing Security verses User Convince.  Also, what issues do I need to consider when I'm building this to increase the difficulty to hack my code and/or users logins as much as practical.  Would I want to blend other security features in to this (NT Security for example)? Ian Skinner Developer Ilsweb ilsweb@pacbell.net

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Fregas
12/30/2002 06:16 PM

Ian, One thing you might want to look at is Authentix.  It provides more robust security thant winnt challenge/response.  It can block individual pages and images based upon referrer, IP, NT Login, ODBC database, etc.  Very very powerful and does not require cookies.  It is a COM component that integrates w/ CF using CFOBJECT. Of course,  your hosting company will have to install it for you if this isn't on your own server.   I think they've upgraded it to some product called web quote but you might be able to pick either one.   http://www.flicks.com/ You are going to have to watch URL/FORM hacks.  Assume that users wanting to break in will view source.  Use CFQUERYPARAM and CFPROCPARAM whenever possible.  If you are using cookies for state/session information, you may want to investigate SSL cookies. Just my 0.02. Fregas > I am writing a User ID/Password login in for a commercial, registered > members only type, Internet site.  Not adult orientated if you care *S*. > > I've written simple CF Login functions before, but this current project that > is going to require a little more true security then I've dealt with before. > I'm asking all the guru's and other experienced CF developers if you can > help with some ideas.  Basically I want to provide a fairly secure site that > doesn't turn away potential users/members/customers. > > What I'm interested in is comments and ideas on balancing Security verses > User Convince.  Also, what issues do I need to consider when I'm building > this to increase the difficulty to hack my code and/or users logins as much > as practical.  Would I want to blend other security features in to this (NT ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Jochem van Dieten
12/30/2002 06:17 PM

Ian Skinner wrote: > I am writing a User ID/Password login in for a commercial, registered > members only type, Internet site.  Not adult orientated if you care *S*.   We don't :-) > I've written simple CF Login functions before, but this current project that > is going to require a little more true security then I've dealt with before. > I'm asking all the guru's and other experienced CF developers if you can > help with some ideas.  Basically I want to provide a fairly secure site that > doesn't turn away potential users/members/customers.   What is secure? Is it a problem if users close their browser and are automatically logged in if they re-open it? Do you need protection against multiple simultaneous logins with the same user account? Etc. > What I'm interested in is comments and ideas on balancing Security verses > User Convince. I think the best balance for the general internet population is currently Digest Authentication or Basic Authentication over SSL. > Would I want to blend other security features in to this (NT > Security for example)? NT Security is IE only, don't do it. If it has to be really secure, use something with smartcards (everybody has one nowadays anyway) and single use passwords. Jochem

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Chris White
12/30/2002 07:11 PM

The post should have been with this message: I have used AuthintiX and it is quite nice.  I have noticed a web hosting company that offers it with their plans when I was looking for something else.  Other things to consider are:  1.  Required min. password length, 2.  Special characters required within the password, 3. Password case sensitive, 4.  Password expiration every 30 days ect., 5. User only allowed to be logged in once, if two users try to sign in using the same user id then blow away the current user session which allows only one user to be logged in, 6.  Min. length for the user id. Chris I am writing a User ID/Password login in for a commercial, registered members only type, Internet site.  Not adult orientated if you care *S*. I've written simple CF Login functions before, but this current project that is going to require a little more true security then I've dealt with before. I'm asking all the guru's and other experienced CF developers if you can help with some ideas.  Basically I want to provide a fairly secure site that doesn't turn away potential users/members/customers.   What I'm interested in is comments and ideas on balancing Security verses User Convince.  Also, what issues do I need to consider when I'm building this to increase the difficulty to hack my code and/or users logins as much as practical.  Would I want to blend other security features in to this (NT Security for example)? Ian Skinner Developer Ilsweb ilsweb@pacbell.net

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Christian Cantrell
12/31/2002 10:16 AM

Chris mentions several very important password-related tips here.  Just   wanted to add a few things. With respect to number 5, it would be easier to prevent the second user   from logging in than it would be to invalidate the first session and   allow the second session to become active, however it is important that   you do it the way Chris describes.  Invariably, someone's browser will   crash in the middle of a session, and they will need log back in to the   application, therefore the logic must be such that the old session gets   blown away and the new session is given precedence. Couple of additional tips: 1. Provide a logout/logoff button.  Make it prominent and encourage   people to use it.  If your users are used to logging out of your   application, it will reduce the possibility of someone picking up   someone else's session on the same workstation, even inadvertently. 2. Use short session expiration intervals.  It can sometime be   inconvenient for users to have to log back in after they have been   distracted by a phone call or a few emails, however it does make for a   more secure system. 3. Consider using the hash() function and storing passwords as MD5   hashes rather than plain text.  The advantage is that the MD5 is   one-way hash, which means that it is not currently possible to reverse   it and discover what the original string was.  This is good for two   reasons.  First, if your database is compromised, your passwords remain   secure (albeit, if your database is compromised, it would be easier to   steal data directly from the database than to log in as someone, but at   least users who use the same password across accounts will have their   other account compromised).  Second, it actually prevents people who   are supposed to have access to the database like your developers from   seeing passwords in clear text, as well.  Again, this mostly serves to   keep other accounts secure, but is generally a good practice.  Note   that the disadvantage of storing passwords as hashes is that you cannot   recover people's passwords for them.  Consider using the password hint   "magic question" paradigm to get around this. 4. Don't provide a "remember me" checkbox on your login page.  Make   people authenticate each and every time.  Again, not overly convenient,   but more secure. Christian On Monday, December 30, 2002, at 07:08 PM, Chris White wrote: ----- Excess quoted text cut - see Original Post for more -----

Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Dwayne Cole
12/30/2002 09:41 PM

Here’s what you might refer to as “imperative dimensions of application security.”   It’s not an exhaustive list because it doesn’t include server maintenance security practices, code encryption, and data transfer security among other things.  Nevertheless, you might want to start by walking through this list and documenting your requirements.   1. Login / Logout Processes .     2. Use Case Access - Rights & Privileges 3. Directory Access - Rights & Privileges 4. Page Access - Rights & Privileges 5. Data Access - Rights & Privileges 6. Encrypting Links and Form Fields 7. Securing SQL statements I'm sure each of the above topics will generate, at least, a 15 message thread.   And frankly there's no "silver bullet" but there are some best practices.  But what ever you do try to gloablize security task as much as possible and make sure that your implemention works well with your coding methodology. Good luck. Prof. Dwayne Cole, MS in MIS, MBA Florida A&M University Certified Advanced ColdFusion Developer 850-591-0212 "It can truely be said that nothing happens until there is vision. But it is equally true that a vision with no underlying sense of purpose, no calling, is just a good idea - all "sound and fury, signifiying nothing."  The Fifth Discipline - Peter Senge ----- Excess quoted text cut - see Original Post for more -----

Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Ian Skinner
12/31/2002 11:38 AM

Thanks for all your responses.  A long summary of all the information I've currently received with questions throughout to follow. Fregas, thanks for the information about Authentix.  Unfortunately this site is being built and launched on a thread-bare, shoe string budget.  All the available monetary resources are pretty well allocated.  But I will defiantly look around when we start actually picking our hosting company to see if they offer it as a package as Chris White suggested. As to ULR/FORM attacks, could somebody provide some good information/resources on what these actually are, and how to properly use the CFQueryParam and CFProceParam to avoid them.  I've read about this best practice several places, but they never really went into specific detail on what the Hacks are, just that you should do to prevent them.  I find it's much easier to write proper code, if I know exactly what the purpose is supposed to be. To answer some of Van Dieten's questions.   What is Secure:  This is going to be a Commercial, Paid, Membership Only type site.  What I want is enough security to reasonably protect our paid content from too easy swiping as well as user abuses such as sharing logins with other un-paid members.  Also, what are some other user abuses of which I may not have considered?   But these security issues must be balanced with Usability.  We can't have so much security, that we turn away too many potential customers due to the difficulty of registering and/or login to our site.  That's largely where I'm asking the community for advice.  What kind's of security measures have the most bang while at the same time the most transparency to the user.  And what kinds of usability do these same Users expect from their security? What is Digest Authentication? That is a new term to me. Smartcards? what are Smartcards in this context?  I don't think I have one? Is this something the general consumer is going to have, or more of a corporate ID/Security type thing? Single use passwords are probably not the way to go for the entire site, but we may use it for a one time preview type thing.  We are trying to sell this service, and that sounds like it would turn away customers, but let me hear if anybody feels otherwise. As Chris White suggested, I am considering minimum length User Names and Passwords as well as requiring stronger passwords with mixed cases and/or special characters.  My question is balancing security and usability what is the minimum characters I should allow.  How strong should I require the password be, without turning away too many customers by making the registration process an ordeal. The paid account is going to be good for one year, so requiring a new password every month is probably a bit extreme.  But again I would love to hear opinions on this. As to allowing only one user to log in, this I had already planned on using. I would love to hear some technical ideas on how to accomplish this?  How do I check who is currently logged on?  How do I blow away the extra user (new or old)?  What else should I consider, such as browser crashes?  Multiple open browser instances?  Multiple versions of browsers (IE, Netscape, Opera, ect)?  If I wanted to log this kind of activity to watch for concentrated Hack attempts, what should I be looking for? Thanks to Dwayne Cole for his great list, I would love if this became a 15 or more message thread.  One of the reasons I came to this community, is that I wasn't really finding a good resource for this kind of information that told you what you need to do, how to do it, and what impact this may have on a commercial site all in one place.  I would find pieces of the puzzle here and there, but it would be great to have a summary of it all and how the different pieces can be fit together. Luckily the security requirements are pretty simple.  We are only going to have two kinds of users, Trial and Paid.  A paid user has access to the entire site for one year.  The Trial user would have access to one section of the site of his choosing for a certain period of time (one day, week, month) yet to be determined.  For the trial user, I was planning on using one time usernames/passwords automatically generated and mailed to an e-mail account.  One time per e-mail account only.  Now, if somebody really wanted to, they could get e-mail account after e-mail account and eventually gain access to the entire site, at least for a short time.  But at only 10 to 15 dollars a year for membership, it's their time their wasting. I would like to know more about encrypting links and Form fields, and securing SQL statements.  What am I looking for here?  What am I trying to prevent? Finally to address Christian Cantrell's suggestions.  Concerning the logout/logoff function.  As well as providing a button, can anybody comment on the ways and problems of providing some kind of automatic logoff if a users closes the browser and/or leaves the site?  I read of one idea where the site was contained inside a "Frame" HTML element and the frame had an "on close" event to run some JavaScript to logoff.  Would this work? Could it cause any potential problems? Are they other ways I might do something like this? When determining how long to set the session expiration.  Can some of you provide some experience on what is a good length is that balances usability with security?  I could easily just pick a number (5, 10, 20 minutes).  But I have no real reason to pick from one or the other. Thanks for the suggestion of using the Hash() function.  I had forgotten that one.  As I understand your comments, there is no way to every unhash the string.  So, for a lost password function, I would have to assign and/or require a replacement, correct?  There would be no way to send the old one. If I don't provide a remember-me function, what are some opinions on how this may affect the usability of the site from the consumers point of view? A question of my own. Are there any issues or concerns I may not know about using Application.cfm for security validation?  Are there any known hacks to bypass the running of this file and getting directly to the content pages? Thanks again for all your comments.  I look forward to reaching that 15+ thread. Ian Skinner ILSweb ilsweb@pacbell.net

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Matt Robertson
12/31/2002 12:15 PM

I don't have any links handy, but I'm sure you'll get some posted. Basically SQL injection attacks, or nasty code of various types, can be input by malicious users on forms or passed via url vars.  Regarding using cfqueryparam, here are three examples for three common db ops. In a select: <cfquery   name="Blah"   datasource="#request.SiteDSN#">   SELECT     filename.EditLevel,     filename.ParentID   FROM filename   WHERE     filename.ID=<cfqueryparam cfsqltype="CF_SQL_NUMERIC" value=#url.ID#>   AND     filename.SubFilter=<cfqueryparam cfsqltype="CF_SQL_VARCHAR" value=#client.SectionFilter#> </cfquery> In an update: <cfquery   datasource="#request.SiteDSN#">   UPDATE filename   SET              filename.PageText=<cfqueryparam cfsqltype="CF_SQL_LONGVARCHAR" value=#form.PageText#>   WHERE   filename.ID=<cfqueryparam cfsqltype="CF_SQL_NUMERIC" value=#client.EditMarker#> </cfquery> In an insert: <cfquery   datasource="#request.SiteDSN#">   INSERT INTO filename   (   ParentID,   PageText,   ModBy   )   VALUES   (   <cfqueryparam cfsqltype="CF_SQL_NUMERIC" value=#client.EditParent#>,   'Text Message Here',   <cfqueryparam cfsqltype="CF_SQL_NUMERIC" value=#client.Producer#>   ) </cfquery> --Matt Robertson-- MSB Designs, Inc. http://mysecretbase.com Thanks for all your responses.  A long summary of all the information I've currently received with questions throughout to follow. Fregas, thanks for the information about Authentix.  Unfortunately this site is being built and launched on a thread-bare, shoe string budget.  All the available monetary resources are pretty well allocated.  But I will defiantly look around when we start actually picking our hosting company to see if they offer it as a package as Chris White suggested. As to ULR/FORM attacks, could somebody provide some good information/resources on what these actually are, and how to properly use the CFQueryParam and CFProceParam to avoid them.  I've read about this best practice several places, but they never really went into specific detail on what the Hacks are, just that you should do to prevent them.  I find it's much easier to write proper code, if I know exactly what the purpose is supposed to be. To answer some of Van Dieten's questions.   What is Secure:  This is going to be a Commercial, Paid, Membership Only type site.  What I want is enough security to reasonably protect our paid content from too easy swiping as well as user abuses such as sharing logins with other un-paid members.  Also, what are some other user abuses of which I may not have considered?   But these security issues must be balanced with Usability.  We can't have so much security, that we turn away too many potential customers due to the difficulty of registering and/or login to our site.  That's largely where I'm asking the community for advice.  What kind's of security measures have the most bang while at the same time the most transparency to the user. And what kinds of usability do these same Users expect from their security? What is Digest Authentication? That is a new term to me. Smartcards? what are Smartcards in this context?  I don't think I have one? Is this something the general consumer is going to have, or more of a corporate ID/Security type thing? Single use passwords are probably not the way to go for the entire site, but we may use it for a one time preview type thing.  We are trying to sell this service, and that sounds like it would turn away customers, but let me hear if anybody feels otherwise. As Chris White suggested, I am considering minimum length User Names and Passwords as well as requiring stronger passwords with mixed cases and/or special characters.  My question is balancing security and usability what is the minimum characters I should allow.  How strong should I require the password be, without turning away too many customers by making the registration process an ordeal. The paid account is going to be good for one year, so requiring a new password every month is probably a bit extreme.  But again I would love to hear opinions on this. As to allowing only one user to log in, this I had already planned on using. I would love to hear some technical ideas on how to accomplish this? How do I check who is currently logged on?  How do I blow away the extra user (new or old)?  What else should I consider, such as browser crashes? Multiple open browser instances?  Multiple versions of browsers (IE, Netscape, Opera, ect)?  If I wanted to log this kind of activity to watch for concentrated Hack attempts, what should I be looking for? Thanks to Dwayne Cole for his great list, I would love if this became a 15 or more message thread.  One of the reasons I came to this community, is that I wasn't really finding a good resource for this kind of information that told you what you need to do, how to do it, and what impact this may have on a commercial site all in one place.  I would find pieces of the puzzle here and there, but it would be great to have a summary of it all and how the different pieces can be fit together. Luckily the security requirements are pretty simple.  We are only going to have two kinds of users, Trial and Paid.  A paid user has access to the entire site for one year.  The Trial user would have access to one section of the site of his choosing for a certain period of time (one day, week, month) yet to be determined.  For the trial user, I was planning on using one time usernames/passwords automatically generated and mailed to an e-mail account.  One time per e-mail account only.  Now, if somebody really wanted to, they could get e-mail account after e-mail account and eventually gain access to the entire site, at least for a short time.  But at only 10 to 15 dollars a year for membership, it's their time their wasting. I would like to know more about encrypting links and Form fields, and securing SQL statements.  What am I looking for here?  What am I trying to prevent? Finally to address Christian Cantrell's suggestions.  Concerning the logout/logoff function.  As well as providing a button, can anybody comment on the ways and problems of providing some kind of automatic logoff if a users closes the browser and/or leaves the site?  I read of one idea where the site was contained inside a "Frame" HTML element and the frame had an "on close" event to run some JavaScript to logoff.  Would this work? Could it cause any potential problems? Are they other ways I might do something like this? When determining how long to set the session expiration.  Can some of you provide some experience on what is a good length is that balances usability with security?  I could easily just pick a number (5, 10, 20 minutes). But I have no real reason to pick from one or the other. Thanks for the suggestion of using the Hash() function.  I had forgotten that one.  As I understand your comments, there is no way to every unhash the string.  So, for a lost password function, I would have to assign and/or require a replacement, correct?  There would be no way to send the old one. If I don't provide a remember-me function, what are some opinions on how this may affect the usability of the site from the consumers point of view? A question of my own. Are there any issues or concerns I may not know about using Application.cfm for security validation?  Are there any known hacks to bypass the running of this file and getting directly to the content pages? Thanks again for all your comments.  I look forward to reaching that 15+ thread. Ian Skinner ILSweb ilsweb@pacbell.net

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Jochem van Dieten
12/31/2002 12:47 PM

Ian Skinner wrote: > > What is Secure:  This is going to be a Commercial, Paid, Membership Only > type site.  What I want is enough security to reasonably protect our paid > content from too easy swiping as well as user abuses such as sharing logins > with other un-paid members.  Also, what are some other user abuses of which > I may not have considered?   Users not sharing the logins but the content they download from your site? If your content is documents/images, have you looked into watermarks? > What is Digest Authentication? That is a new term to me. RFC 2617, it is basically a beefed up version of Basic Security, supported by all recent browsers (IE 5+, Netscape 6+, Opera 6+). > Smartcards? what are Smartcards in this context?  I don't think I have one? > Is this something the general consumer is going to have, or more of a > corporate ID/Security type thing? It is usually a corporate thing (RSA sells some nice products) for high-security environment, but most users have one (without realizing it) because every mobile phone has a built-in smartcard. It is a bit of a pain to access them unless you buy some SMS based throwaway password system from a third party. Also, banks sometimes have smartcards and function as a TTP for their customers. > Single use passwords are probably not the way to go for the entire site, but > we may use it for a one time preview type thing.  We are trying to sell this > service, and that sounds like it would turn away customers, but let me hear > if anybody feels otherwise. It can be an inconvenience. But sometimes the added security is worth it. ----- Excess quoted text cut - see Original Post for more ----- For this an SMS syste would be nice. Switching phones is more expensive as switching emailaddresses. > When determining how long to set the session expiration.  Can some of you > provide some experience on what is a good length is that balances usability > with security?  I could easily just pick a number (5, 10, 20 minutes).  But > I have no real reason to pick from one or the other. Depends on the content. For 200 page legal documents, 5 minutes might be a little short :-) > Thanks for the suggestion of using the Hash() function.  I had forgotten > that one.  As I understand your comments, there is no way to every unhash > the string.  So, for a lost password function, I would have to assign and/or > require a replacement, correct?  There would be no way to send the old one. Correct. > If I don't provide a remember-me function, what are some opinions on how > this may affect the usability of the site from the consumers point of view? They won't mind. They will just use the remember password functionality from their browser. > Are there any issues or concerns I may not know about using Application.cfm > for security validation?  Are there any known hacks to bypass the running of > this file and getting directly to the content pages? Just remember it only runs for .cfm pages. Jochem

Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Ian Skinner
12/31/2002 03:43 PM

Jacen van Dieten wrote: > Users not sharing the logins but the content they download from your > site? If your content is documents/images, have you looked into watermarks? No, this is another new one for me, watermarks on websites? Any good pointers before I dive into the Google search and see where that leads, after I manage to filter out all the paper watermark links. The content will be primarily HTML text with pictures for visual appeal. The biggest "added value" to the site is not each individual piece of text, but the extensive cross linking capability we are going to provide to a wide range of related pieces of text.  Thus, copying a single "page" or three isn't going to be that big a deal, as long as they don't get the entire database. Evan so, the material is going to be officially and competently copywrited, so we would theoretically have legal recourse over the stealing of the content.  But I sure don't mind any idea that forestalls the possibility of having to fight this out in court some day. *Grin* Ian Skinner ilsweb ilsweb@pacbell.net

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Jochem van Dieten
01/01/2003 07:48 AM

Ian Skinner wrote: > Jacen van Dieten wrote: ??? ----- Excess quoted text cut - see Original Post for more ----- I don't think watermarking text is feasible unless you distribute it as .pdf or something. Image watermarking is pretty easy with programs like Photoshop. It doesn't help against people stealing, but it makes proving the content is yours a whole lot easier if you might end up in court. Jochem


<< Previous Thread Today's Threads Next Thread >>

Search cf-talk

April 23, 2014

<<   <   Today   >   >>
Su Mo Tu We Th Fr Sa
     1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30       

Designer, Developer and mobile workflow conference