Kallithea issues archive

Issue #16: allow users to set secondary password for use with DVCS client

Reported by: Mark Edgington
State: new
Created on: 2014-08-08 02:41
Updated on: 2014-08-20 15:09


If Kallithea is configured to use LDAP authentication within an organization, and LDAP is also used for several resources in the organization, then the user's LDAP password is fairly precious, and shouldn't end up in a plaintext file to enable automatic authentication (when pushing/pulling changes over HTTP).

A way of working around this problem would be to allow a user to set a secondary password, which could also be used for authentication. This way it would be possible for a user to put this made-up password in their hgrc file, for example, without concern that it's a big security issue to do so. The worst that can happen if someone gets this password is that someone will have access to the person's Kallithea account.



Comment by Mads Kiilerich, on 2014-08-08 11:40

The right way to fix this will be to use the keyring extension on the client side, right?

... and really using keyring might depend on some serious cleanup of it and integration with Mercurial core ...

Comment by Mads Kiilerich, on 2014-08-08 11:46

Also ... where should this secondary pw be stored and managed? Wouldn't that be pretty much an alternative LDAP?

Comment by Mark Edgington, on 2014-08-08 17:02

It's not exactly an alternative to LDAP, because there may be situations where you want only to have people who are in an LDAP database able to log in / create an account, and then you would want to give those people the ability to set an "extra password". It would seem sensible to have this be just another optional field they can fill out under the "my account" setting page. It would be stored/managed in whatever database non-LDAP passwords / accounts get stored in (i.e. the postgres / sqlite db that Kalithea is configured to use).

Comment by Christian Oyarzun, on 2014-08-08 17:22

Would you still need this feature once ssh key support is added?

Comment by Mark Edgington, on 2014-08-08 17:27

I think SSH key support would be a definite improvement, but not everyone will run Kallithea on a server where they can create new accounts, and allow SSH access. But, typically if you are going to use LDAP for authentication, you are in a setting where you have root access to the machine that Kallithea is running on...

At least for Windows users, I think the 'extra password' option is a lot less painful -- creating and setting up an SSH key under Windows requires a somewhat higher level of effort for beginner users.

Comment by Christian Oyarzun, on 2014-08-08 17:39

The ssh implementation does not require you to create ssh system accounts on the Kallithea server. All user connect using the same system account, it then uses the connecting user's ssh key to authenticate the user against Kallithea's db. This is similar to how bitbucket works. Everyone uses the hg account for ssh. eg ssh://hg@bitbucket.org/conservancy/kallithea.

Comment by Mark Edgington, on 2014-08-08 22:41

Christian, I understand how it works -- but one ssh account does need to be created, and root access is required for this, as well as setting this user's default shell.

Comment by domruf, on 2014-08-20 08:09

I'm not sure I completely understand your problem. If you want a password just for kallithea why not simple use the internal authentication?

BTW to prevent users from storing their password in plain text I set up our kallithea instance with kerberos authentication (Windows Active Directory single sign on) https://bitbucket.org/domruf/kallithea/commits/branch/repoze.who https://bitbucket.org/domruf/hgssoauthentication

Comment by Mark Edgington, on 2014-08-20 15:09

Dominik, when a user is authenticated via LDAP when logging in to the web interface (this is a requirement in my case), the user currently has no choice but to authenticate with their LDAP password. Even if he tries to change the "internal authentication" password you mention (via the "My Account -> Password" page), the new password is not accepted afterwards, and only the LDAP password will continue to work.

The purpose of this issue is to find a way for users who have initially created an account using their LDAP username/password to not be forced to use their LDAP username/password with their git or mercurial client.