On Fri, Sep 30, 2011 at 6:01 PM, Dmitry Chestnykh
wrote:
> On Sep 30, 2011, at 17:58 , Stephan Beal wrote:
> I'm thinking about reusing the current "cookie" column for the per-user
> secret key. But this will require careful handling of migrations to avoid
> introducing security bugs. Not sure wha
On Sep 30, 2011, at 17:58 , Stephan Beal wrote:
> Multiple login sessions will require that some fields be migrated out of the
> user table and into a new table. The anon user does not store the cookie data
> in the user table (because it would log out all other anonymous users), using
> only t
On Fri, Sep 30, 2011 at 4:55 PM, Dmitry Chestnykh
wrote:
> No. Maybe we should create a new branch for overhaul of cookie code to
> allow multiple sessions?
>
i think that's a good idea - i'm not comfortable enough with the voodoo of
the login mechanism to make this change in a working branch :).
On Sep 30, 2011, at 16:15 , Stephan Beal wrote:
> On Fri, Sep 30, 2011 at 4:02 PM, Dmitry Chestnykh
> wrote:
> I have attached a patch to sha.c with HMAC implementation, and double-signing.
>
> :-D
>
> Basically, if zKey is a random secret string stored in the database, and
> zRest is a conc
On Fri, Sep 30, 2011 at 4:02 PM, Dmitry Chestnykh
wrote:
> I have attached a patch to sha.c with HMAC implementation, and
> double-signing.
>
:-D
> Basically, if zKey is a random secret string stored in the database, and
> zRest is a concatenation of the values you want to store in the cookie (
> i know almost nothing about security-related issues - 90% of what i know
> about cookie security i learned from grokking fossil's login cookie (i had to
> for the JSON login implementation). That means: i'll use whatever code i can
> get to do this, as long as i don't actually have to come up
On Fri, Sep 30, 2011 at 1:45 PM, Dmitry Chestnykh
wrote:
> 1. Store some random bytes in database per user. This string will be a
> secret_key for HMAC.
> ...
4. To logout all sessions, go to step 1 (replace secret_key in database with
> a new randomly generated one, thus invalidating all cookies
> Advantages are that no state is stored in the database and multiple logins
> are possible, with simpler code.[2] You can invalidate all logins by changing
> the secret key, but can't invalidate individual sessions.
>
> But that would mean a logout on one client would log out all others, doesn'
On Thu, Sep 15, 2011 at 10:22 AM, Stephan Beal wrote:
>
>
>> Advantages are that no state is stored in the database and multiple logins
>> are possible, with simpler code.[2] You can invalidate all logins by
>> changing the secret key, but can't invalidate individual sessions.
>>
>
> But that woul
On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers wrote:
> For example, you could form the string
>
> stephan:192.168.0
>
> then sign it with the secret key, and get
>
> stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162
>
That is in essence what Richard has done already. He uses the firs
On Thu, Sep 15, 2011 at 6:19 AM, Altu Faltu wrote:
> It would be simple to have one auth token for each login and purge stale
> auth tokens regularly. Purging stale tokens should be a matter of few SQLs
> for the current backend of fossil, sqlite.
>
In principal it's simple, yes, but the current
On 15 Sep 2011, at 00:17, Stephan Beal wrote:
>
> As Richard mentioned earlier, the current fossil login mechanism does not
> tolerate a given user being logged in multiple times (each new login
> invalidates the previous one). While this almost certainly isn't a real
> limitation for the HTML
logins: the problem and a
potential solution
On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig < r...@cheshireeng.com > wrote:
... from a user experience point of view. The thread stalled out
after a patch was offered by Kyle McKay[1] that would have
dropped the use of the IP adderss
> Ross Berteig:
> I should be possible to support more than one session cookie per
> user, but then you would need a process to occasionally purge
> stale sessions from the server. You could do that check on any
> session validation, if its been long enough since the last check.
> Or at least check
On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig wrote:
> ...
from a user experience point of view. The thread stalled out
> after a patch was offered by Kyle McKay[1] that would have
> dropped the use of the IP adderss in the session cookie hash,
> allowing the same session cookie to be used from
At 04:33 PM 9/14/2011, Stephan Beal wrote:
>
>i think if we got rid of (gasp!) the IP check we could easily
>implement this, but i can't just take that part out without a
>blessing from the higher powers.
I found a thread that I started back in March of 2010 about this
from a user experience
On Thu, Sep 15, 2011 at 1:30 AM, Ross Berteig wrote:
> At 04:17 PM 9/14/2011, Stephan Beal wrote:
> >Would this modification be acceptable in fossil? i know it's a
> >bit unconventional, but should be a fairly simple change to make
> >with no backwards compatibility concerns (because fossil doesn
At 04:17 PM 9/14/2011, Stephan Beal wrote:
>Would this modification be acceptable in fossil? i know it's a
>bit unconventional, but should be a fairly simple change to make
>with no backwards compatibility concerns (because fossil doesn't
>support multiple logins for one user right now).
Chiming
Hi again,
As Richard mentioned earlier, the current fossil login mechanism does not
tolerate a given user being logged in multiple times (each new login
invalidates the previous one). While this almost certainly isn't a real
limitation for the HTML interface, it will eventually become one for the
19 matches
Mail list logo
