Opened 6 years ago
Closed 2 years ago
#205 closed defect (fixed)
Local authorization - clear text passwords
Reported by: | pferreir | Owned by: | arescope |
---|---|---|---|
Priority: | blocker | Milestone: | v1.2 |
Component: | Security | Version: | 0.96.x |
Keywords: | Cc: |
Description
Passwords are still stored/retrieved in clear text. This is highly insecure (since they are sent over unencrypted mail).
Encrypting them using some hashing algorithm (sha1?) and creating a password-reset service (by e-mail) would probably be the best solution.
Change History (12)
comment:1 Changed 6 years ago by jbenito
- Version changed from 0.98 to 0.97
comment:2 Changed 5 years ago by jbenito
- Component changed from General to Security
- Milestone changed from v0.98 to v1.0
- Version changed from 0.97.0 to 0.96.x
comment:3 Changed 3 years ago by jbenito
- Milestone changed from v1.0 to v1.4
comment:4 Changed 2 years ago by jbenito
- Milestone changed from v1.4 to v1.2
- Owner set to arescope
- Status changed from new to assigned
comment:5 Changed 2 years ago by jbenito
- Priority changed from normal to blocker
comment:6 Changed 2 years ago by arescope
comment:7 Changed 2 years ago by arescope
- Status changed from assigned to awaiting_merge
comment:8 Changed 2 years ago by hoffmann
Even if InDiCo needs to choose one scrambling algorithm (SHA, MD5) to generate the stored password sequence, it should be able to understand several ones.
The standard for LDAP is (I beleive)
{MD5}b1946ac92492d2347c6235b4d2611184
or
to store (and recognize) effectively the same password.
Reason: Sometimes it is very useful to import passwords from an existing base of users. Mostly it is possible to extract them in scrambled form without too many problems.
comment:9 follow-up: ↓ 10 Changed 2 years ago by jmonnich
I think it would be nicer to use the scheme that e.g. crypt() and bcrypt use. For example, a bcrypt-based hash would look like this:
$2a$12$bfmXFmBR2ouhuQanXO8XxO6oMMIjV0EA8DUBT910qDlvVo9sslNZO
and a sha256-based hash would look like this:
$6$test$fFq5g1mn56TbMIVZSWBHVvKcuVWb9NbnowWnb.thcmIF0Jhc6qh2GAsUXIBHr1W2YQ89rT4pMrk.YDf3AMjoJ0
This format allows metadata such as the used salt to be included - and supporting salts is incredibly important nowadays.
For python there seems to be a nice library available that handles both bcrypt, pbkdf2 and other crypt()-based (md5 etc.) hashes:
>>> from cryptacular.core import DelegatingPasswordManager >>> from cryptacular.bcrypt import BCRYPTPasswordManager >>> from cryptacular.pbkdf2 import PBKDF2PasswordManager >>> from cryptacular.crypt import CRYPTPasswordManager, SHA512CRYPT >>> delegator = DelegatingPasswordManager(preferred=BCRYPTPasswordManager(), fallbacks=(PBKDF2PasswordManager(), CRYPTPasswordManager(SHA512CRYPT))) >>> delegator.encode('asdf') '$2a$10$QtGHi9jN5WS493tWF6S4Z.7mhUkXKOgF5bEG5zGqVlqO6CS5ThR1.' >>> delegator.check('$2a$10$QtGHi9jN5WS493tWF6S4Z.7mhUkXKOgF5bEG5zGqVlqO6CS5ThR1.', 'asdf') True >>> delegator.check('$2a$10$QtGHi9jN5WS493tWF6S4Z.7mhUkXKOgF5bEG5zGqVlqO6CS5ThR1.', 'asdfx') False
I guess it's also possibly to convert a plain unsalted MD5 hash to a format suitable for it...
comment:10 in reply to: ↑ 9 Changed 2 years ago by hoffmann
Replying to jmonnich:
I think it would be nicer to use the scheme that e.g. crypt() and bcrypt use.
Sure, if you want to use salts, that's fine. Almost everything is better than plain text pwd storage.
My point is that, even if you need to define one optimal format for InDiCo to use by default, you should keep in mind that people may want to migrate from other complete user databases, that do not necessarily support the same crypt format. It would be nice, if InDiCo could accept them at least. On the first password change by user, the default optimal InDiCo choice would then be used for pwd scrambling.
MD5 and SHA1 is kind of a minimum need, crypt & Co. a nice plus.
comment:11 Changed 2 years ago by jbenito
- Status changed from awaiting_merge to merging
comment:12 Changed 2 years ago by jbenito
- Resolution set to fixed
- Status changed from merging to closed
Integrated in #939