Project

General

Profile

Actions

User story #3942

closed

Technique "password" field type enhancement: add option to set prehashed password

Added by Olivier Mauras over 7 years ago. Updated about 5 years ago.

Status:
Rejected
Priority:
1
Category:
Web - Config management
Target version:
Suggestion strength:
User visibility:
Effort required:

Description

The password part of the userManagement technique lacks the possibility to set a pre-hashed password.


Related issues

Related to Rudder - Bug #4342: Several issues with userManagement technique v2.0RejectedNicolas CHARLES2014-01-09Actions
Is duplicate of Rudder - Bug #6493: Missing "don't change" password hash type in userManagementReleasedJonathan CLARKE2016-02-25Actions
Actions #1

Updated by Nicolas PERRON over 7 years ago

  • Assignee set to François ARMAND

Thanks for the feedback ! It seems that this "basic" behavior is not yet implemented.

François, could you look into this please ?

Actions #2

Updated by Jonathan CLARKE over 7 years ago

  • Category set to 14
  • Status changed from New to 8
  • Target version set to 2.8.0~beta1

This is indeed important. Currently, it is impossible to set passwords unless we have the cleartext password.

Actions #3

Updated by Jonathan CLARKE over 7 years ago

  • Subject changed from Technique enhancement: userManagement add option to set prehashed password to Technique "password" field type enhancement: add option to set prehashed password

Just a clarification of the title: this isn't about the userManagement technique, but the builtin field type "password" in Rudder.

Actions #4

Updated by Jonathan CLARKE over 7 years ago

A workaround for this issue may be to "cheat" and change the Techniques's definition to allow "CLEAR" password algorithms, and paste in the hash... It should get passed through.

This is an ugly hack though, so we still need to fix this issue.

Actions #5

Updated by Jonathan CLARKE over 7 years ago

Jonathan CLARKE wrote:

A workaround for this issue may be to "cheat" and change the Techniques's definition to allow "CLEAR" password algorithms, and paste in the hash... It should get passed through.

This is an ugly hack though, so we still need to fix this issue.

Er, I wrote nonsense, it's not "CLEAR" but "PLAIN", as explained in http://www.rudder-project.org/foswiki/Development/TechniqueXML#Available_Hash_format.

Actions #6

Updated by Nicolas PERRON over 7 years ago

  • Target version changed from 2.8.0~beta1 to 2.8.0~rc1

Should this "feature" be added in Rudder 2.8 ?

Actions #7

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 2.8.0~rc1 to Ideas (not version specific)

This won't be done in 2.8.0, postponed to later version

Actions #8

Updated by Nicolas CHARLES over 7 years ago

I'm not sure, but it seems to me the feature is there since 2.6, and "only" need to be included in the technique; isn't it ?

Actions #9

Updated by Alex Tkachenko over 7 years ago

The userManagement technique included with the latest release still does not include the plain option. I would vote for it not so much because of adding pre-hashed passwords, but rather to be able to specify something like "!*" to indicate that this account should be locked as a matter of applied policy.

Actions #10

Updated by François ARMAND about 7 years ago

  • Status changed from 8 to Discussion
  • Assignee changed from François ARMAND to Jonathan CLARKE

So, do we agree that this ticket is not about the password field lacking something, as it actually has a "don't touch what I get you" choice (named PLAIN), that can be used both for disabling accounts or set prehashed password, but in the missing inclusion of that choice in the technique ?

Jon, could you explain why you consider it a hack (has it was one of the intended functionnality of that choice ?)

Actions #11

Updated by François ARMAND about 6 years ago

  • Assignee changed from Jonathan CLARKE to Benoît PECCATTE
  • Target version changed from Ideas (not version specific) to 2.10.10

Benoit, have an idea on that one ?

Actions #12

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 2.10.10 to 2.10.11
Actions #13

Updated by Benoît PECCATTE about 6 years ago

  • Assignee changed from Benoît PECCATTE to François ARMAND

First, the problem on the User management technique has been addressed for Alex case (None as a value for the password).

The problem for "passthrough" password is still there. The only option I see (even in Rudder 3.0) is: md5, sha256 or sha512, we are missing "PLAIN".

After analysis, PLAIN is supported by Rudder. So this is because the technique has never been updated to use it.
But I would like to say that Rudder should ignore this <PASSWORDHASH> </PASSWORDHASH> entry and use all available methods instead. We should not have to update all techniques each time Rudder implements a new scheme.

I'm not retargetting to 3.1 yet, but i think we should since it should be implemented in Rudder.

Actions #14

Updated by François ARMAND about 6 years ago

  • Assignee changed from François ARMAND to Benoît PECCATTE

In fact, the list in <PASSWORDHASH></PASSWORDHASH> was a required feature so that we could easely add or remove provided scheme.

OK, so I would say that's a bug to not have "plain" in the list (and give it an other name/description).

Actions #15

Updated by Benoît PECCATTE about 6 years ago

  • Assignee changed from Benoît PECCATTE to François ARMAND

Removing some can be usefull, but having to add them when we want all af them is counterproductive.
Can we have a "all" keyword for this field ?

Actions #16

Updated by François ARMAND about 6 years ago

It should already be the case if you let empty <PASSWORDHASH></PASSWORDHASH>.

Hum, I just checked the documentation, and it says that the list must not be empty. It needs tests...

Actions #17

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 2.10.11 to 2.10.12
Actions #18

Updated by Benoît PECCATTE about 6 years ago

  • Category changed from 14 to Web - Config management
Actions #19

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 2.10.12 to 2.10.13
Actions #20

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 2.10.13 to 2.10.14
Actions #21

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 2.10.14 to 2.10.15
Actions #22

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 2.10.15 to 2.10.16
Actions #23

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.10.16 to 2.10.17
Actions #24

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.10.17 to 2.10.18
Actions #25

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.10.18 to 2.10.19
Actions #26

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.10.19 to 2.10.20
Actions #27

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.10.20 to 2.11.18
Actions #28

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 2.11.18 to 2.11.19
Actions #29

Updated by Vincent MEMBRÉ about 5 years ago

  • Target version changed from 2.11.19 to 2.11.20
Actions #30

Updated by Alexis MOUSSET about 5 years ago

  • Is duplicate of Bug #6493: Missing "don't change" password hash type in userManagement added
Actions #31

Updated by Alexis MOUSSET about 5 years ago

  • Status changed from Discussion to Rejected
Actions

Also available in: Atom PDF