Skip to main content
WolfShade
WolfShade
Legend
July 24, 2016
Answered

Best practices for secure login of website/app

  • July 24, 2016
  • 2 replies
  • 3265 views

Hello, all,

I am nearing the end of my side-project, and could use some advice on creating a secure login for it.

First off, I would really like to avoid using CFLOGIN/CFLOGINUSER, if at all possible.  I know a lot of people use it, and all, but after some things that I've read online, I'm not comfortable using it.  I would like to create one from scratch.  I've Googled for it, but I'm not finding anything that DOESN'T use CFLOGIN.

That said, another thing that I'm concerned about is keeping an admin logged in beyond what any session scope can do.  No matter how long I programmatically set the session for, I believe that it cannot surpass what is set in CFAdmin.  So if I manually set the session to expire in an hour, but the CFAdmin says 20 minutes, the session won't last beyond 20 minutes.  😕😕

One more thing.    (I kind of feel like Columbo, now)  Concurrent logins.  I want to disallow them, and set it so that if an admin is logged in, already, that a second login without a logout, first, will deny the second attempt at logging on.  Is this difficult to arrange?

I have included the class for BCrypt in my admin section and was planning on using that for encrypting the passwords before inserting them into the database.  Yea, or nay?

V/r,

^_^

UPDATE: ALSO - how difficult is it to set it so that I can see who is logged on, and "boot" anyone (assuming I think their account has been compromised)?

    This topic has been closed for replies.
    Correct answer Steve Sommers

    Hi, Steve Sommers​,

    Thanks for your reply.

    I've never used CFLogin and to tell you the truth, I'm not sure what it  does any different than simply tracking the login status yourself in the  session scope. I've read the doc a few times and it's unclear to me  what it does.

    Ditto.  But I have read posts by respected CF "celebrities" that give CFLOGIN a less-than-desirable status in my mind, so in addition to not fully understanding how it works (despite repeated reading of documentation), I'm not inclined to use it because of that.

    So, how do _you_ track the login status?  I've never created a secure login; where I'm currently employed, the network handles authentication/authorization via Common Access Cards.

    But remember, this is an idle timeout so as long as the session is being used it will not timeout.

    Precisely.  The people who will be administering this project aren't the type to write a news item in Notepad, then copy/paste into the CMS; rather, they'd most likely bring up the page to enter an article, and type the whole thing out.  Great, if it takes less than 20 minutes!  But, you know.. formatting, proofreading, etc.  There's a good chance that they would timeout before hitting the submit button.  I _could_ write a JavaScript function that would keep the page alive, but that feels "hackish", to me.  Was hoping for a better alternative.

    Booting someone out, should be doable but a little work needs to be  done. You need to track active logins within the application scope  yourself. I have not done this but it sounds like a fun project and I  would guess there might even be an article or two around on this topic.

    Hmm.. sounds like I should shelf that for v1.1, then.    This project, even though I'm doing it for free, is way behind, already.  Maybe a future update.

    The original login is no longer accessible to the user so blocking this  new request may only frustrate users. Just something to think about and  this may require some of the same logic as the "booting someone out"  mentioned above.

    Point conceded.  Hadn't thought about people who just close their browsers without logging off.  I was more concerned with an authorized user being booted by someone who compromised their account, but you're right - clearing the first session to make the second session authorized is the best practice.

    V/r,

    ^_^


    WolfShade wrote:

    So, how do _you_ track the login status? I've never created a secure login; where I'm currently employed, the network handles authentication/authorization via Common Access Cards.

    I create a login page, authenticate the user and if valid I create a user bean (I use FW/1 and it likes beans and after you get the hang of them they are flexible and powerful) and store this bean in the session scope. The bean includes any rights the user may have (admin, standard user, editor, etc.). Then somewhere in the request startup process I check the rights required for the requested page or action and validate against the user bean (or if the user bean even exists in the event of a user not logged in). To logout, simply delete the user bean from the session.

    You may want to research a little more about how to apply rights and roles to a user and site. I based the framework that I use on an article for FuseBox and it described rights as locks and keys -- locks applied to the site and keys given to users. Once you have a basic framework the rest is easier than you may think at this time.

    2 replies

    S
    Steve Sommers
    Legend
    August 29, 2016

    I'm not sure where the "CFLOCATION would issue a new CFID and CFTOKEN" came from but I use it all the time, almost exclusively without issue. The FW/1 framework that I use does use the cfheader logic and I simply assumed it was more efficient or something but I have never had an issue CFLOCATION.

    WolfShade
    WolfShadeAuthor
    Legend
    July 25, 2016

    Has anyone created a custom secure login for a website or webapp that did not use CFLOGIN?

    V/r,

    ^_^

    S
    Steve Sommers
    Legend
    July 25, 2016

    In no particular order...

    I've never used CFLogin and to tell you the truth, I'm not sure what it does any different than simply tracking the login status yourself in the session scope. I've read the doc a few times and it's unclear to me what it does.

    BCrypt, definitely or something similar. Make sure you are using a one-way hash function of some sort as opposed to a two-way encryption/decryption function. I like to use com.lambdaworks.crypto.SCryptUtil, but CF11+ comes with similar native functions either within CF or within the jars that come with CF.

    The newer CF admin page has default session timeframes and maximum timeframes. You cannot exceed the maximum idle setting from the application. But remember, this is an idle timeout so as long as the session is being used it will not timeout.

    Booting someone out, should be doable but a little work needs to be done. You need to track active logins within the application scope yourself. I have not done this but it sounds like a fun project and I would guess there might even be an article or two around on this topic.

    Lastly the single login, the thing to worry about is that more times than not the last attempt, or the attempt you would be blocking in your example, is the most accurate attempt so it would be better to kill the previous login sessions. Often people close browsers or shutoff their computer and then return to the site. The original login is no longer accessible to the user so blocking this new request may only frustrate users. Just something to think about and this may require some of the same logic as the "booting someone out" mentioned above.

    S
    Steve SommersCorrect answer
    Legend
    July 26, 2016

    Hi, Steve Sommers​,

    Thanks for your reply.

    I've never used CFLogin and to tell you the truth, I'm not sure what it  does any different than simply tracking the login status yourself in the  session scope. I've read the doc a few times and it's unclear to me  what it does.

    Ditto.  But I have read posts by respected CF "celebrities" that give CFLOGIN a less-than-desirable status in my mind, so in addition to not fully understanding how it works (despite repeated reading of documentation), I'm not inclined to use it because of that.

    So, how do _you_ track the login status?  I've never created a secure login; where I'm currently employed, the network handles authentication/authorization via Common Access Cards.

    But remember, this is an idle timeout so as long as the session is being used it will not timeout.

    Precisely.  The people who will be administering this project aren't the type to write a news item in Notepad, then copy/paste into the CMS; rather, they'd most likely bring up the page to enter an article, and type the whole thing out.  Great, if it takes less than 20 minutes!  But, you know.. formatting, proofreading, etc.  There's a good chance that they would timeout before hitting the submit button.  I _could_ write a JavaScript function that would keep the page alive, but that feels "hackish", to me.  Was hoping for a better alternative.

    Booting someone out, should be doable but a little work needs to be  done. You need to track active logins within the application scope  yourself. I have not done this but it sounds like a fun project and I  would guess there might even be an article or two around on this topic.

    Hmm.. sounds like I should shelf that for v1.1, then.    This project, even though I'm doing it for free, is way behind, already.  Maybe a future update.

    The original login is no longer accessible to the user so blocking this  new request may only frustrate users. Just something to think about and  this may require some of the same logic as the "booting someone out"  mentioned above.

    Point conceded.  Hadn't thought about people who just close their browsers without logging off.  I was more concerned with an authorized user being booted by someone who compromised their account, but you're right - clearing the first session to make the second session authorized is the best practice.

    V/r,

    ^_^


    WolfShade wrote:

    So, how do _you_ track the login status? I've never created a secure login; where I'm currently employed, the network handles authentication/authorization via Common Access Cards.

    I create a login page, authenticate the user and if valid I create a user bean (I use FW/1 and it likes beans and after you get the hang of them they are flexible and powerful) and store this bean in the session scope. The bean includes any rights the user may have (admin, standard user, editor, etc.). Then somewhere in the request startup process I check the rights required for the requested page or action and validate against the user bean (or if the user bean even exists in the event of a user not logged in). To logout, simply delete the user bean from the session.

    You may want to research a little more about how to apply rights and roles to a user and site. I based the framework that I use on an article for FuseBox and it described rights as locks and keys -- locks applied to the site and keys given to users. Once you have a basic framework the rest is easier than you may think at this time.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices