Login Handling

[Steve Piercy]

In reference to a couple of threads, what kind of built-in features does Knop have to handle:

(1)  attempts to login again with an account that is currently logged in
(2)  repeated failed login attempts/lockouts

http://www.nabble.com/Multi-user-Knop-td14126565.html#a14126570
http://www.nabble.com/Mastering-logging-using-knop_user-td20325613.html#a20325613
http://www.nabble.com/Suggested-change-in-login-handling-for-knop_user-td20339003.html#a20342801

If not built-in, does anyone have sample code to share?  I'd like to avoid reinventing the wheel if possible.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Jolle Carlestam-3]

13 jul 2009 kl. 21.53 skrev Steve Piercy - Web Site Builder:

> In reference to a couple of threads, what kind of built-in features  
> does Knop have to handle:
>
> (1)  attempts to login again with an account that is currently  
> logged in
> (2)  repeated failed login attempts/lockouts
>
> http://www.nabble.com/Multi-user-Knop-td14126565.html#a14126570
> http://www.nabble.com/Mastering-logging-using-knop_user-td20325613.html#a20325613
> http://www.nabble.com/Suggested-change-in-login-handling-for-knop_user-td20339003.html#a20342801
>
> If not built-in, does anyone have sample code to share?  I'd like to  
> avoid reinventing the wheel if possible.

The user type does not yet have those features. And it doesn't appear  
to be on Johans TODO list. I don't use the features so I can't help  
you out with ready-mades either. Especially number two would be nice.

Sorry

HDB
Jolle

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Johan Solve-2]

At 12.53 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>In reference to a couple of threads, what kind of built-in features does Knop have to handle:
>
>(1)  attempts to login again with an account that is currently logged in

Nothing here.

>(2)  repeated failed login attempts/lockouts

Only slightly implemented. A counter is maintained per session, and an incrementing delay between failed login attempts is enforced. This is per session and not per user name, so multiple different session trying the same user name are not tracked.

knop_user -> 'loginattempt_count' keeps track of the number of failed login attempts. The counter is reset on successful login.


Contributions are welcome.
--
     Johan Sölve    [FSA Member, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:joh-n@...
 (spam-safe email address, replace '-' with 'a')

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Monday, July 13, 2009, inbox_js@... (Johan Solve) pronounced:

>At 12.53 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>>In reference to a couple of threads, what kind of built-in features does Knop have
>to handle:
>>
>>(1)  attempts to login again with an account that is currently logged in
>
>Nothing here.

A comment from Bil:

    When visiting the login page, all existing sessions should be
    terminated.  Then if the user successfully logs in again, then
    they get a new session.

The sledgehammer approach would be to simply not allow the user to access the login page while logged in.  That would also prevent a user from logging in with a different username.  Now that I think more about it, it would be better handled programmatically outside of Knop.

>>(2)  repeated failed login attempts/lockouts
>
>Only slightly implemented. A counter is maintained per session, and an incrementing
>delay between failed login attempts is enforced. This is per session and not per
>user name, so multiple different session trying the same user name are not tracked.
>
>knop_user -> 'loginattempt_count' keeps track of the number of failed login
>attempts. The counter is reset on successful login.

Putting together how Knop tracks failed login attempts in a session and another comment from Bil:

    If you immediately give all visitors a session ID, then continue
    to use it after the visitor has signed in, then your site is
    vulnerable to session fixation attacks.

Let's say a user is assigned a session named "s_fail" prior to successful login or is redirected to the login page after requesting a page requiring authentication.  s_fail is maintained through failed login attempts.  s_fail could track the count of attempts and logic could control whether the user is allowed additional attempts.  On successful login, a new session "s_user" is created and any session vars needed from s_fail are assigned to s_user.

Does anyone see any advantages or disadvantages with doing this?  The only thing I can imagine is perhaps there is some internal session for knop_user that I don't know about which tracks the loginattempt_count, but I did not see any in the types.  Does it exist?

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[bilcorry]

Steve Piercy - Web Site Builder wrote on 7/13/2009 9:01 PM:

> On Monday, July 13, 2009, inbox_js@... (Johan Solve) pronounced:
>
>> At 12.53 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>>> In reference to a couple of threads, what kind of built-in features does Knop have
>> to handle:
>>> (1)  attempts to login again with an account that is currently logged in
>> Nothing here.
>
> A comment from Bil:
>
>     When visiting the login page, all existing sessions should be
>     terminated.  Then if the user successfully logs in again, then
>     they get a new session.

That bit of advice originated from Greg Willits, but it's something I agree with as it tightens security.


> The sledgehammer approach would be to simply not allow the user to access the login page while logged in.  That would also prevent a user from logging in with a different username.  Now that I think more about it, it would be better handled programmatically outside of Knop.

Don't do this unless you plan to handle complaints from users.  I've implemented something similar and what we found was that users will close the browser, then open it a bit later, and can't log in until their session expires.  They hated it.  It's better to terminate the session of the person currently logged in and log in the new person -- if they're the same, it won't be a big deal; if they're sharing a password, then they'll boot each other off.

>>> (2)  repeated failed login attempts/lockouts
>> Only slightly implemented. A counter is maintained per session, and an incrementing
>> delay between failed login attempts is enforced. This is per session and not per
>> user name, so multiple different session trying the same user name are not tracked.
>>
>> knop_user -> 'loginattempt_count' keeps track of the number of failed login
>> attempts. The counter is reset on successful login.
>
> Putting together how Knop tracks failed login attempts in a session and another comment from Bil:
>
>     If you immediately give all visitors a session ID, then continue
>     to use it after the visitor has signed in, then your site is
>     vulnerable to session fixation attacks.
>
> Let's say a user is assigned a session named "s_fail" prior to successful login or is redirected to the login page after requesting a page requiring authentication.  s_fail is maintained through failed login attempts.  s_fail could track the count of attempts and logic could control whether the user is allowed additional attempts.  On successful login, a new session "s_user" is created and any session vars needed from s_fail are assigned to s_user.
>
> Does anyone see any advantages or disadvantages with doing this?  The only thing I can imagine is perhaps there is some internal session for knop_user that I don't know about which tracks the loginattempt_count, but I did not see any in the types.  Does it exist?

Since your "s_fail" session is entirely tied to the browser cookie, the user could reset the count by removing the cookie.  You want to keep the count tied to the user's server-side profile, so regardless of the number of sessions, you always know their current try/fail login attempts.


- Bil


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Monday, July 13, 2009, bil@... (Bil Corry) pronounced:

>Steve Piercy - Web Site Builder wrote on 7/13/2009 9:01 PM:
>> On Monday, July 13, 2009, inbox_js@... (Johan Solve) pronounced:
>>
>>> At 12.53 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>>>> In reference to a couple of threads, what kind of built-in features does Knop
>have
>>> to handle:
>>>> (1)  attempts to login again with an account that is currently logged in
>>> Nothing here.
>>
>> A comment from Bil:
>>
>>     When visiting the login page, all existing sessions should be
>>     terminated.  Then if the user successfully logs in again, then
>>     they get a new session.
>
>That bit of advice originated from Greg Willits, but it's something I agree with as
>it tightens security.
>
>
>> The sledgehammer approach would be to simply not allow the user to access the
>login page while logged in.  That would also prevent a user from logging in with a
>different username.  Now that I think more about it, it would be better handled
>programmatically outside of Knop.
>
>Don't do this unless you plan to handle complaints from users.  I've implemented
>something similar and what we found was that users will close the browser, then open
>it a bit later, and can't log in until their session expires.  They hated it.  It's
>better to terminate the session of the person currently logged in and log in the new
>person -- if they're the same, it won't be a big deal; if they're sharing a
>password, then they'll boot each other off.

Excellent point.  For another app where I intend to use Knop, families share the same computer, and this would antagonize them.

So it looks like killing all sessions on the Login is the preferred method.

>>>> (2)  repeated failed login attempts/lockouts
>>> Only slightly implemented. A counter is maintained per session, and an
>incrementing
>>> delay between failed login attempts is enforced. This is per session and not per
>>> user name, so multiple different session trying the same user name are not
>tracked.
>>>
>>> knop_user -> 'loginattempt_count' keeps track of the number of failed login
>>> attempts. The counter is reset on successful login.
>>
>> Putting together how Knop tracks failed login attempts in a session and another
>comment from Bil:
>>
>>     If you immediately give all visitors a session ID, then continue
>>     to use it after the visitor has signed in, then your site is
>>     vulnerable to session fixation attacks.
>>
>> Let's say a user is assigned a session named "s_fail" prior to successful login or
>is redirected to the login page after requesting a page requiring authentication.  
>s_fail is maintained through failed login attempts.  s_fail could track the count of
>attempts and logic could control whether the user is allowed additional attempts.  
>On successful login, a new session "s_user" is created and any session vars needed
>from s_fail are assigned to s_user.
>>
>> Does anyone see any advantages or disadvantages with doing this?  The only thing I
>can imagine is perhaps there is some internal session for knop_user that I don't
>know about which tracks the loginattempt_count, but I did not see any in the types.  
>Does it exist?
>
>Since your "s_fail" session is entirely tied to the browser cookie, the user could
>reset the count by removing the cookie.  You want to keep the count tied to the
>user's server-side profile, so regardless of the number of sessions, you always know
>their current try/fail login attempts.

That sounds like I cannot use the knop_user -> 'loginattempt_count' because it is session based.  Correct?

So would this be one way to handle the situation?

Modify my db to include columns for counting login attempts, a datetime of last attempt, and a datetime for lock per username, e.g.

    user.login_attempts
    user.login_last_attempt_dt
    user.login_lock_dt

For each login submitted that passes validation but fails, increment the counter and update the last attempt datetime.

When the counter reaches X, update both the last attempt and lock datetime fields, and lock the account for Y minutes (or do whatever else is deemed appropriate).

I followed this diagram as a guide.

http://pageblocks.org/ftrs/api_auth

I cannot imagine how else to implement a similar process without a database.  I know Knop is designed to be lightweight and avoid stepping into the design of db schema, but here is one situation where i think it would be valuable.  Instead of including it in the core, perhaps a plugin or module would be appropriate?

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Johan Solve-2]

At 19.01 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>The only thing I can imagine is perhaps there is some internal session for knop_user that I don't know about which tracks the loginattempt_count, but I did not see any in the types.  Does it exist?

Knop doesn't have any session handling of its own. Knop_user relies on an instance being stored as a session variable.

>I know Knop is designed to be lightweight and avoid stepping into the design of db schema, but here is one situation where i think it would be valuable.  Instead of including it in the core, perhaps a plugin or module would be appropriate?

Optionally specifying field names for such uses would be useful. There are already other optional field names that can be specified when creating a user instance. So if those fields are specified, Knop could transparently switch to using them instead of session based instance variables. Progressive enhancement...

Knop_user is the least finished ctype and any contributions are welcome.


--
     Johan Sölve    [FSA Member, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:joh-n@...
 (spam-safe email address, replace '-' with 'a')

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Tuesday, July 14, 2009, inbox_js@... (Johan Solve) pronounced:

>At 19.01 -0700 2009-07-13, Steve Piercy - Web Site Builder wrote:
>>The only thing I can imagine is perhaps there is some internal session for
>>knop_user that I don't know about which tracks the loginattempt_count, but I did not
>>see any in the types.  Does it exist?
>
>Knop doesn't have any session handling of its own. Knop_user relies on an instance
>being stored as a session variable.

Okay, thanks for confirming.

>>I know Knop is designed to be lightweight and avoid stepping into the design of db
>>schema, but here is one situation where i think it would be valuable.  Instead of
>>including it in the core, perhaps a plugin or module would be appropriate?
>
>Optionally specifying field names for such uses would be useful. There are already
>other optional field names that can be specified when creating a user instance. So
>if those fields are specified, Knop could transparently switch to using them instead
>of session based instance variables. Progressive enhancement...
>
>Knop_user is the least finished ctype and any contributions are welcome.

To get me started with optional field names for the user type, I assume that I could use passwordfield as a template and build on it, yes?

For using optional field names, I assume that the fields must exist in the same table in the database object used by the user type, yes?

In user.inc I see a bunch of TODOs and a Purpose section with notes, all of which look familiar from earlier discussions.  I see a couple of items that I have the opportunity to work on for a current project and another coming up, specifically handling failed login attempts and logging actions.

Finally, I was looking at how to store and retrieve stuff in the Knop user type without adding yet another column to the user table.  It appears that to take full advantage of CRUD operations in Knop, one must keep all fields in a single table and use that table as part of the database object.  Is that correct?  Currently I just execute SQL statements to make up for what I could not figure out on my own.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Jolle Carlestam-3]

14 jul 2009 kl. 13.08 skrev Steve Piercy - Web Site Builder:

> Finally, I was looking at how to store and retrieve stuff in the  
> Knop user type without adding yet another column to the user table.  
> It appears that to take full advantage of CRUD operations in Knop,  
> one must keep all fields in a single table and use that table as  
> part of the database object.  Is that correct?  Currently I just  
> execute SQL statements to make up for what I could not figure out on  
> my own.

Im' not sure this applies. But I have some installations where all  
user info is stored in one table. That's easy to handle. In other  
installations I have some user info stored in a contact table. What I  
do to get to that data is another search in that table and then  
inserting the found info into the user object using setdata. That way  
I can retrieve the info from the user object the same way regardless  
of how I found the info.

HDB
Jolle

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Tuesday, July 14, 2009, list@... pronounced:

>14 jul 2009 kl. 13.08 skrev Steve Piercy - Web Site Builder:
>
>> Finally, I was looking at how to store and retrieve stuff in the  
>> Knop user type without adding yet another column to the user table.  
>> It appears that to take full advantage of CRUD operations in Knop,  
>> one must keep all fields in a single table and use that table as  
>> part of the database object.  Is that correct?  Currently I just  
>> execute SQL statements to make up for what I could not figure out on  
>> my own.
>
>Im' not sure this applies. But I have some installations where all  
>user info is stored in one table. That's easy to handle. In other  
>installations I have some user info stored in a contact table. What I  
>do to get to that data is another search in that table and then  
>inserting the found info into the user object using setdata. That way  
>I can retrieve the info from the user object the same way regardless  
>of how I found the info.

It sort of applies, at least in regards to storing information in the user object.  However I want to also update the database with database->saverecord, but I don't think it will work.  My situation is slightly different than yours.  Whereas you select one record from one table that corresponds to the user, I pull many records from one or many tables using JOINs.  You could easily use database->saverecord for a one-table database object, but I don't see how the Knop database object supports updates for JOINs.  I hope I'm wrong.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Jolle Carlestam-3]

14 jul 2009 kl. 17.21 skrev Steve Piercy - Web Site Builder:

>
> On Tuesday, July 14, 2009, list@... pronounced:
>
>> 14 jul 2009 kl. 13.08 skrev Steve Piercy - Web Site Builder:
>>
>>> Finally, I was looking at how to store and retrieve stuff in the
>>> Knop user type without adding yet another column to the user table.
>>> It appears that to take full advantage of CRUD operations in Knop,
>>> one must keep all fields in a single table and use that table as
>>> part of the database object.  Is that correct?  Currently I just
>>> execute SQL statements to make up for what I could not figure out on
>>> my own.
>>
>> Im' not sure this applies. But I have some installations where all
>> user info is stored in one table. That's easy to handle. In other
>> installations I have some user info stored in a contact table. What I
>> do to get to that data is another search in that table and then
>> inserting the found info into the user object using setdata. That way
>> I can retrieve the info from the user object the same way regardless
>> of how I found the info.
>
> It sort of applies, at least in regards to storing information in  
> the user object.  However I want to also update the database with  
> database->saverecord, but I don't think it will work.  My situation  
> is slightly different than yours.  Whereas you select one record  
> from one table that corresponds to the user, I pull many records  
> from one or many tables using JOINs.  You could easily use database-
> >saverecord for a one-table database object, but I don't see how the  
> Knop database object supports updates for JOINs.  I hope I'm wrong.

I'm not savvy enough to do that even using SQL statements directly. If  
I need to store information in several tables I do that by multiple  
inlines, or creating multiple Knop database objects. Not the optimal  
solution, I know.
I've learned how to retrieve info from several tables at once and that  
no problem using the database object since I can send SQL to it. But  
shouldn't it be possible to do the same for a save? You send SQL to  
the database object that saves to several tables instead of searching.

HDB
Jolle

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Wednesday, July 15, 2009, list@... pronounced:

>I've learned how to retrieve info from several tables at once and that  
>no problem using the database object since I can send SQL to it. But  
>shouldn't it be possible to do the same for a save? You send SQL to  
>the database object that saves to several tables instead of searching.

Yes, you can perform multiple table updates (saves) in SQL.

    update
        t1, t2
    set
        t1.value = t2.value
    where
        t1.id = t2.id

However, I meant using database->saverecord.  According to the Help doc:
   
    -> saverecord
    Updates a specific database record.
    Parameters:
        -fields (required array) Lasso-style field values in pair array

To me a "record" implies "within the scope of a single table".  So you have to resort to using database->select for updating multiple tables.

    -> select
    perform database query, either Lass-style pair array or SQL
    statement.->recorddata returns a map with all the fields for the
    first found record. If multiple records are returned, the
    records can be accessed either through ->inlinename or
    ->records_array.
    Parameters:
        -search (optional array) Lasso-style search parameters in pair
        array
        -sql (optional string) Raw sql query

That's still perfectly functional for running SQL statements, and it's what I do.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Johan Solve-2]

At 11.12 -0700 2009-07-15, Steve Piercy - Web Site Builder wrote:
>    -> saverecord
>    Updates a specific database record.
>    Parameters:
>        -fields (required array) Lasso-style field values in pair array
>
>To me a "record" implies "within the scope of a single table".  So you have to resort to using database->select for updating multiple tables.

Correct. ->saverecord is a single table affair. Ideas for how this can be expanded elegantly are welcome.

As for your other ponderings (ponders?), I'll have to rest my case until I've turned on my brain again. It's in vacation mode right now.
--
     Johan Sölve    [FSA Member, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:joh-n@...
 (spam-safe email address, replace '-' with 'a')

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[bilcorry]

Bil Corry wrote on 7/13/2009 10:19 PM:

> Steve Piercy - Web Site Builder wrote on 7/13/2009 9:01 PM:
>> Let's say a user is assigned a session named "s_fail" prior to
>> successful login or is redirected to the login page after
>> requesting a page requiring authentication.  s_fail is maintained
>> through failed login attempts.  s_fail could track the count of
>> attempts and logic could control whether the user is allowed
>> additional attempts.  On successful login, a new session "s_user"
>> is created and any session vars needed from s_fail are assigned to
>> s_user.
>>
>> Does anyone see any advantages or disadvantages with doing this?
>> The only thing I can imagine is perhaps there is some internal
>> session for knop_user that I don't know about which tracks the
>> loginattempt_count, but I did not see any in the types.  Does it
>> exist?
>
> Since your "s_fail" session is entirely tied to the browser cookie,
> the user could reset the count by removing the cookie.  You want to
> keep the count tied to the user's server-side profile, so regardless
> of the number of sessions, you always know their current try/fail
> login attempts.

I came across this today, it has some interesting ideas:

        http://coding-insecurity.blogspot.com/2009/05/effective-account-lockout.html


- Bil


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Thursday, July 16, 2009, bil@... (Bil Corry) pronounced:

>Bil Corry wrote on 7/13/2009 10:19 PM:
>> Steve Piercy - Web Site Builder wrote on 7/13/2009 9:01 PM:
>>> Let's say a user is assigned a session named "s_fail" prior to
>>> successful login or is redirected to the login page after
>>> requesting a page requiring authentication.  s_fail is maintained
>>> through failed login attempts.  s_fail could track the count of
>>> attempts and logic could control whether the user is allowed
>>> additional attempts.  On successful login, a new session "s_user"
>>> is created and any session vars needed from s_fail are assigned to
>>> s_user.
>>>
>>> Does anyone see any advantages or disadvantages with doing this?
>>> The only thing I can imagine is perhaps there is some internal
>>> session for knop_user that I don't know about which tracks the
>>> loginattempt_count, but I did not see any in the types.  Does it
>>> exist?
>>
>> Since your "s_fail" session is entirely tied to the browser cookie,
>> the user could reset the count by removing the cookie.  You want to
>> keep the count tied to the user's server-side profile, so regardless
>> of the number of sessions, you always know their current try/fail
>> login attempts.
>
>I came across this today, it has some interesting ideas:
>
>   http://coding-insecurity.blogspot.com/2009/05/effective-account-lockout.html

In the Knop user type, there is a TODO referring to such an implementation:

    if((self -> 'loginattempt_count') >= 5);
        // login delay since last attempt was made
        (self -> '_debug_trace') -> insert(tag_name + ': Too many login attempts, wait until ' + (2 * (self -> 'loginattempt_count')) + ' seconds has passed since last attempt.');
        while(((date - (self -> 'loginattempt_date')) -> second) <  (2 * (self -> 'loginattempt_count')) // at least 5 seconds, longer the more attempts
            && loop_count < 100); // rescue sling
            sleep(200);
        /while;
    /if;
...
    // TODO:
    // - block username for a while after too many attempts
    (self -> 'loginattempt_count') += 1;
    (self -> 'loginattempt_date') = date; // keep track of when last login attempt happened

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[bilcorry]

Bil Corry wrote on 7/16/2009 11:18 AM:

> Bil Corry wrote on 7/13/2009 10:19 PM:
>> Steve Piercy - Web Site Builder wrote on 7/13/2009 9:01 PM:
>>> Let's say a user is assigned a session named "s_fail" prior to
>>> successful login or is redirected to the login page after
>>> requesting a page requiring authentication.  s_fail is maintained
>>> through failed login attempts.  s_fail could track the count of
>>> attempts and logic could control whether the user is allowed
>>> additional attempts.  On successful login, a new session "s_user"
>>> is created and any session vars needed from s_fail are assigned to
>>> s_user.
>>>
>>> Does anyone see any advantages or disadvantages with doing this?
>>> The only thing I can imagine is perhaps there is some internal
>>> session for knop_user that I don't know about which tracks the
>>> loginattempt_count, but I did not see any in the types.  Does it
>>> exist?
>> Since your "s_fail" session is entirely tied to the browser cookie,
>> the user could reset the count by removing the cookie.  You want to
>> keep the count tied to the user's server-side profile, so regardless
>> of the number of sessions, you always know their current try/fail
>> login attempts.
>
> I came across this today, it has some interesting ideas:
>
> http://coding-insecurity.blogspot.com/2009/05/effective-account-lockout.html

Related, here's Google's take on password recovery:

        Google - Password strength and account recovery options
        http://googleonlinesecurity.blogspot.com/2009/07/password-strength-and-account-recovery.html

- Bil


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/

[Steve Piercy]

On Monday, July 20, 2009, bil@... (Bil Corry) pronounced:

>Bil Corry wrote on 7/16/2009 11:18 AM:
>> I came across this today, it has some interesting ideas:
>>
>>  http://coding-insecurity.blogspot.com/2009/05/effective-account-lockout.html
>
>Related, here's Google's take on password recovery:
>
>   Google - Password strength and account recovery options
>  
>http://googleonlinesecurity.blogspot.com/2009/07/password-strength-and-account-
>recovery.html

Another interesting identity verification method involves providing a telephone number during signup.  When the user loses their account information, they can have the web site initiate a telephone call and display a PIN.  When the user answers the call, they are prompted to enter the PIN.  If successful, the user is granted access to their account.  Google Local Business Center uses this technique.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<web@...>                  <http://www.StevePiercy.com/>

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <knop@...>.
To unsubscribe, E-mail to: <knop-off@...>
Send administrative queries to  <knop-request@...>
List archive http://www.nabble.com/Knop-Framework-Discussion-f29076.html
Project homepage http://montania.se/projects/knop/
Google Code has the latest downloads at http://code.google.com/p/knop/