incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: git commit: updated refs/heads/master to c98ba56
Date Sat, 01 Jun 2013 08:53:25 GMT
On Jun 1, 2013 6:37 AM, "Jason Smith" <jhs@iriscouch.com> wrote:

>
> Both methods have their own restrictions.
>
> When editing an .ini file, you *can* trivially set a password cyphertext
> (just paste it in), but you cannot set a password to literally
> "-pbkdf2-...". (You could calculate the hash yourself and then paste
that.)

I'm not sure what you mean there. What you can do actually  is pasting the
full hash or the or setting a plain text password that will be transformed
when couchdb start. The password is detected as an hash if it match a
signature (for now -hashtype-... ).


>
> When using the API, you *can* trivially set a password to literal
> "-pbkdf2-..." but you cannot set the password to some cyphertext, as-is.
> (And reversing the hash back to the plaintext is impossible.)

Actually yes, anything passed via the HTTP API is considered as a plain
text password. Which is what you are trying to fix as far as I understand.


The question is why do you want to let the possibility to pass a password
looking like an hash? Who want to really do that ? When you could handle it
like the api for the ini file does. Ie. checking if the string passed match
an hash signature and if yes consider this is an hash, else this is a plain
text password that need to be encoded. Just like the ini API,

>
> In other words, even if you are admin on couch A and admin on couch B, you
> cannot synchronize the admin passwords using the API.
>
That's not true actually if you pass an ini file with an hash. I do this to
deploy some nodes actually.


- benoit

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message