On Sat, Feb 06, 2010 at 05:31:29PM -0800, Chris Anderson wrote:
I'd love to hear people's ideas about what schema to store the passwords in:
maybe something like this in the _user doc:
{
credentials : {
type : bcrypt,
whatever else
}
}
Don't reinvent the wheel; do exactly what
On Sun, Feb 7, 2010 at 1:21 AM, Brian Candler b.cand...@pobox.com wrote:
On Sat, Feb 06, 2010 at 05:31:29PM -0800, Chris Anderson wrote:
I'd love to hear people's ideas about what schema to store the passwords in:
maybe something like this in the _user doc:
{
credentials : {
type :
On Sun, Feb 07, 2010 at 10:23:17AM -0800, Chris Anderson wrote:
password: plain
password: {CRYPT}$1$foo$bar
password: {SHA1}...
password: {SSHA1}...with salt...
... etc
That doesn't sound bad at all.
...
If we can't find an Erlang library, is there a spec we should look at
while
On Sat, Feb 6, 2010 at 5:11 PM, Matt Lyon sanehat...@gmail.com wrote:
+1 to using a password scheme that allows for future extensibility
and/or change.
I'd love to hear people's ideas about what schema to store the passwords in:
maybe something like this in the _user doc:
{
credentials : {
On 25 Jan 2010, at 21:02, Chris Anderson wrote:
On Tue, Jan 5, 2010 at 10:21 PM, Benoit Chesneau bchesn...@gmail.com wrote:
--
There is a blowfish encryption implementation available in javascript.
doesn't bcrypt stand for blowfish crypt ?
On 27 Jan 2010, at 07:27, Brian Candler wrote:
On Wed, Jan 27, 2010 at 06:33:12AM -0800, Jan Lehnardt wrote:
I'm not a crypto expert, but it seems we can get away with sha1 if we use
HMAC instead of just hashing + salting:
Errm, do you mean HMAC with a fixed server-side secret?
This
On Wed, Jan 27, 2010 at 8:12 AM, Jan Lehnardt j...@apache.org wrote:
On 27 Jan 2010, at 07:27, Brian Candler wrote:
On Wed, Jan 27, 2010 at 06:33:12AM -0800, Jan Lehnardt wrote:
I'm not a crypto expert, but it seems we can get away with sha1 if we use
HMAC instead of just hashing + salting:
On Wed, Jan 27, 2010 at 08:12:28AM -0800, Jan Lehnardt wrote:
Quoting http://en.wikipedia.org/wiki/HMAC:
The values of ipad and opad are not critical to the security of the
algorithm
If you mean these by secret, otherwise I don't follow.
*The* secret. HMAC is a function with two
On Wed, Jan 27, 2010 at 08:26:39AM -0800, Chris Anderson wrote:
My reasoning here is that a SHA implementation is easier to come by
universally
than a bcrypt one.
More secure without more dependencies, which works for me.
SHA1 != HMAC_SHA1
If you want a format that doesn't tie you down
On Wed, Jan 27, 2010 at 5:26 PM, Chris Anderson jch...@apache.org wrote:
On Wed, Jan 27, 2010 at 8:12 AM, Jan Lehnardt j...@apache.org wrote:
On 27 Jan 2010, at 07:27, Brian Candler wrote:
On Wed, Jan 27, 2010 at 06:33:12AM -0800, Jan Lehnardt wrote:
I'm not a crypto expert, but it seems we
On Tue, Jan 5, 2010 at 10:21 PM, Benoit Chesneau bchesn...@gmail.com wrote:
--
There is a blowfish encryption implementation available in javascript.
doesn't bcrypt stand for blowfish crypt ?
On 25 Dec 2009, at 14:11, Dirkjan Ochtman wrote:
On Fri, Dec 25, 2009 at 00:58, Chris Anderson jch...@apache.org wrote:
So I think I'm gonna switch to docids like user:jch...@apache.org
and user:Monty4eva. If this is a stupid idea please convince me not
to do it.
Making the user IDs the
On 27 Dec 2009, at 20:46, Benoit Chesneau wrote:
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote:
I haven't yet investigated what it takes to prevent the basic-auth
popup. It will be very hard to convince me that is acceptable to
trigger it. I understand the
On 6 Jan 2010, at 03:25, Chris Anderson wrote:
On Tue, Jan 5, 2010 at 10:50 AM, Chris Anderson jch...@apache.org wrote:
I'd be happy to see the users db design document ported to erlang, so
we can use erlang's bcrypt (assuming license is ok).
One problem here is I think that we currently
FYI - I have pushed the account branch to Apache SVN.
I plan to merge it to trunk in the next couple of days. Please test,
especially if you are making heavy use of authentication / oauth /
cookie auth.
There may be some small backwards incompatibilities, hopefully these
are slight enough that
On Tue, Jan 5, 2010 at 7:38 PM, Chris Anderson jch...@apache.org wrote:
FYI - I have pushed the account branch to Apache SVN.
I plan to merge it to trunk in the next couple of days. Please test,
especially if you are making heavy use of authentication / oauth /
cookie auth.
There may be
On Tue, Jan 5, 2010 at 10:45 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Jan 5, 2010 at 7:38 PM, Chris Anderson jch...@apache.org wrote:
FYI - I have pushed the account branch to Apache SVN.
I plan to merge it to trunk in the next couple of days. Please test,
especially if you are
On Tue, Jan 5, 2010 at 10:50 AM, Chris Anderson jch...@apache.org wrote:
I'd be happy to see the users db design document ported to erlang, so
we can use erlang's bcrypt (assuming license is ok).
One problem here is I think that we currently ship with the native
query server disabled. We'd
On Wed, Jan 6, 2010 at 3:25 AM, Chris Anderson jch...@apache.org wrote:
On Tue, Jan 5, 2010 at 10:50 AM, Chris Anderson jch...@apache.org wrote:
I'd be happy to see the users db design document ported to erlang, so
we can use erlang's bcrypt (assuming license is ok).
One problem here is I
Here is an implementation of blowfish in javascript :
http://farfarfar.com/scripts/encrypt/
- benoit
Chris Anderson wrote:
My first thought is that there's got to be some common identifier in
your LDAP space (like a UUID or something) that is the real identifier
here. But I'm just guessing, maybe there's not...
There is a UID I could use - but my idea was to leave this a little
more open, so
On Mon, Jan 4, 2010 at 11:31 AM, Joscha Feth jos...@feth.com wrote:
Chris Anderson wrote:
My first thought is that there's got to be some common identifier in
your LDAP space (like a UUID or something) that is the real identifier
here. But I'm just guessing, maybe there's not...
There is a
Hi, just catching up on this very nice thread. I'm +1 on using the login for
the docid instead of triggering a view lookup, for the reasons Chris outlined.
Regarding resistance to brute force attacks, bcrypt storage is definitely
better than salted sha-anything, and Colin Percival's scrypt[1]
On Mon, Jan 4, 2010 at 1:26 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, just catching up on this very nice thread. I'm +1 on using the login for
the docid instead of triggering a view lookup, for the reasons Chris
outlined. Regarding resistance to brute force attacks, bcrypt storage
On Mon, Jan 4, 2010 at 10:26 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, just catching up on this very nice thread. I'm +1 on using the login for
the docid instead of triggering a view lookup, for the reasons Chris
outlined. Regarding resistance to brute force attacks, bcrypt storage
On Jan 4, 2010, at 4:54 PM, Chris Anderson wrote:
On Mon, Jan 4, 2010 at 1:26 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, just catching up on this very nice thread. I'm +1 on using the login
for the docid instead of triggering a view lookup, for the reasons Chris
outlined. Regarding
On Fri, Jan 1, 2010 at 3:16 AM, Chris Anderson jch...@apache.org wrote:
On Thu, Dec 24, 2009 at 8:27 AM, Chris Anderson jch...@apache.org wrote:
Devs,
I'm attempting to make more sense of CouchDB's authentication system.
The current system is a proverbial ball of spaghetti. I'm still in the
On Sun, Jan 3, 2010 at 5:28 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Fri, Jan 1, 2010 at 3:16 AM, Chris Anderson jch...@apache.org wrote:
On Thu, Dec 24, 2009 at 8:27 AM, Chris Anderson jch...@apache.org wrote:
Devs,
I'm attempting to make more sense of CouchDB's authentication
On Sun, Jan 03, 2010 at 08:31:19AM -0800, Chris Anderson wrote:
On Sun, Jan 3, 2010 at 5:28 AM, Benoit Chesneau bchesn...@gmail.com wrote:
Just tested it, admin creation seem to work during the test I've done
at least admin user is created, for the rest I don't know, am not sure
yet what
On Sun, Jan 3, 2010 at 11:50 AM, Sam Bisbee sbis...@computervip.com wrote:
On Sun, Jan 03, 2010 at 08:31:19AM -0800, Chris Anderson wrote:
On Sun, Jan 3, 2010 at 5:28 AM, Benoit Chesneau bchesn...@gmail.com wrote:
Just tested it, admin creation seem to work during the test I've done
at least
On Sun, Jan 03, 2010 at 12:55:29PM -0800, Chris Anderson wrote:
On Sun, Jan 3, 2010 at 11:50 AM, Sam Bisbee sbis...@computervip.com wrote:
On Sun, Jan 03, 2010 at 08:31:19AM -0800, Chris Anderson wrote:
On Sun, Jan 3, 2010 at 5:28 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
Just
On Sun, Jan 3, 2010 at 3:17 PM, Sam Bisbee sbis...@computervip.com wrote:
I was thinking we could even add some code which loads the admin
config into a cookie, and then clears admins. When the tests are done
it can re-configure the admins.
This scares me: if the browser/client crashes
On Thu, Dec 31, 2009 at 8:50 PM, Steve Olson steveo...@gmail.com wrote:
Chris, and other interested devs:
I have become a CouchDB Evangelist for our development group (100+
developers) and I'll be giving a presentation in January to many decision
makers.
One of my weaknesses in web
On Sun, Jan 3, 2010 at 4:02 PM, Chris Anderson jch...@apache.org wrote:
On Sun, Jan 3, 2010 at 3:17 PM, Sam Bisbee sbis...@computervip.com wrote:
I was thinking we could even add some code which loads the admin
config into a cookie, and then clears admins. When the tests are done
it can
On Mon, Dec 28, 2009 at 3:39 AM, Joscha Feth jos...@feth.com wrote:
Chris Anderson wrote:
I'm attempting to make more sense of CouchDB's authentication system.
The current system is a proverbial ball of spaghetti. I'm still in the
investigation stage of my work, and I'm writing this to
On Thu, Dec 24, 2009 at 8:27 AM, Chris Anderson jch...@apache.org wrote:
Devs,
I'm attempting to make more sense of CouchDB's authentication system.
The current system is a proverbial ball of spaghetti. I'm still in the
investigation stage of my work, and I'm writing this to clarify my
Chris, and other interested devs:
I have become a CouchDB Evangelist for our development group (100+
developers) and I'll be giving a presentation in January to many decision
makers.
One of my weaknesses in web development is working with authentication and
that has been one of the main lynch
Chris Anderson wrote:
I'm attempting to make more sense of CouchDB's authentication system.
The current system is a proverbial ball of spaghetti. I'm still in the
investigation stage of my work, and I'm writing this to clarify my
thoughts and solicit feedback.
Hi Chris,
It's maybe not the
Sorry was off, hosting family for christmas.
- benoit
On Fri, Dec 25, 2009 at 12:58 AM, Chris Anderson jch...@apache.org wrote:
On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson jch...@apache.org wrote:
I think it is
On Sun, Dec 27, 2009 at 10:47 AM, Benoit Chesneau bchesn...@gmail.com wrote:
The _session by form is already in place and used in some apps. I'm
full for a json api, but also I think that both form and json ap
should be supported as well and since orm api is already in place and
used by apps,
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote:
I haven't yet investigated what it takes to prevent the basic-auth
popup. It will be very hard to convince me that is acceptable to
trigger it. I understand the principles of RESTful service discovery,
I just think they
On Sun, Dec 27, 2009 at 11:46 AM, Benoit Chesneau bchesn...@gmail.comwrote:
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote:
Not really since salt is available and hash is only sha1. I think we
could make it harder but I agree with a strong encryption we don't
On Sun, Dec 27, 2009 at 10:09 PM, Glenn Rempe gl...@rempe.us wrote:
On Sun, Dec 27, 2009 at 11:46 AM, Benoit Chesneau bchesn...@gmail.comwrote:
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote:
Not really since salt is available and hash is only sha1. I think we
On Sun, Dec 27, 2009 at 1:33 PM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sun, Dec 27, 2009 at 10:29 PM, Benoit Chesneau bchesn...@gmail.com wrote:
also there is already some erlang code :
http://github.com/skarab/erlang-bcrypt
- benoit
Ah that what adam mentionned too.
Cool --
More updates in the interest of keeping my work transparent. I don't
think it's clean enough yet to solicit help, but it is clean enough to
be worth backing up to Github.
The relevant tests are cookie_auth and users_db (they have a lot of
overlap, I'll be cleaning that up.)
The branch will live
On Fri, Dec 25, 2009 at 00:58, Chris Anderson jch...@apache.org wrote:
So I think I'm gonna switch to docids like user:jch...@apache.org
and user:Monty4eva. If this is a stupid idea please convince me not
to do it.
Making the user IDs the document IDs seems to make sense, but I'm not
sure what
On Fri, Dec 25, 2009 at 5:11 AM, Dirkjan Ochtman djc.ocht...@gmail.com wrote:
On Fri, Dec 25, 2009 at 00:58, Chris Anderson jch...@apache.org wrote:
So I think I'm gonna switch to docids like user:jch...@apache.org
and user:Monty4eva. If this is a stupid idea please convince me not
to do it.
On Fri, Dec 25, 2009 at 16:40, Chris Anderson jch...@apache.org wrote:
Not yet, but who knows what the next hundred years will bring. :)
YAGNI. ;)
Christmas cheers,
Dirkjan
On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau bchesn...@gmail.com wrote:
I'm also thinking that the /_session handler should speak JSON
primarily (but I'll probably leave in the ability to handle
form-encoded request bodies as well).
We could just detect http headers and provide the
49 matches
Mail list logo
