Description

MoinMoin stores user passwords in SHA1-hashed form on the local filesystem. People who can read these files can find out the hashed password. This is similar to the way passwords are stored in Unix /etc/passwd files.

However, for MoinMoin, the hashed password can be used everywhere in place of the unencrypted password. For example, everybody who can read the user files can log in as that user with the hash.

• Because: MoinMoin enable it. see:

  • MoinMoin/user.py [in moin-1.3, I don't check in moin-1.5]

    •    1         #!python
         2         self.enc_password = ""
         3         if password:
         4             if password.startswith('{SHA}'):
         5                 self.enc_password = password
         6             else:
         7                 try:
         8                     self.enc_password = encodePassword(password)
         9                 except UnicodeError:
        10                     pass # Should never happen
      

    • I think it isn't a good idea. -- FrankieChow 2005-12-27 13:00:00

Since passwords are hashed in the same way on all MoinMoin wikis, the hash can also be used for logging in as that user on other MoinMoin wikis if the same password is used.

• I cann't catch more about you meaning:
  • In the linux world. the password is encrypt in crypt like this:

       1    #!python
       2    from crypt import crypt
       3    print crypt('password', '$1$salt$')
    

  • you can running the code and result is:

       $1$salt$qJH7.N4xYta3aEG/dfqo/0

  What about the $1$salt$ ?

  this is the salt, and salt is can find in the enc_password. SSHA is same of crypt. cracker can see the salt in hash string, and make the same hash string. -- FrankieChow 2005-12-27 13:10:00

Of course, perfect security is not possible, especially not against people who have read access to the wiki data. However, the current setup promises more than it delivers, because encryption is used even though the plain text is not (much) more valuable than the encrypted form. Thus, I think that encryption lulls the user into a false sense of security. I'd either make the mechanism more strict or use no encryption at all.

Steps to reproduce

1. Set up two wikis and register the same user with the same password on two wikis.
2. Look at the user file for one wiki and identify the line providing the encrypted password.
3. Use this password to log in as that user at the other wiki.

Workaround

Use different passwords for each wiki.

Discussion

Initial discussion on http://thread.gmane.org/gmane.comp.web.wiki.moin.general/2005.

Suggested options for changing this:

1. Do not encrypt the passwords and add some information in the documentation telling the user that they should not use the same password elsewhere. So users won't expect more security than actually is implemented.

2. Encrypt the password with an additional "salt" that is different for each wiki, or for each combination of wiki and user. For example, the salt could be randomly generated as the user creates his account. Do not store sha1(password), but sha1(password + salt). This prevents the encrypted password from being used to login at other wikis where the same password is used. (Update: Since user IDs are random, they could be used as a salt.)

   • I don't agree it: becaue the userid is fix.
   salt
   1. I suggest the salt is random to create for everytime the member change his password,
   2. Just keep the salt in the password hash.
   3. Don't pass the password hash through the internet.

      • -- FrankieChow 2005-12-27 13:20:00

   • In fact, User IDs are not really random. Much too weak for a safe system ... -- AlexanderSchremmer 2005-02-15 17:25:17

     • They can be made random enough easily.

       • Please use this code to encode the SSHA password

   1 import sha
   2 import base64
   3 
   4 def encode_SSHA_password ( password, salt ):
   5     p_ssha = sha.new( password )
   6     p_ssha.update( salt )
   7     p_ssha_base64 = base64.encodestring(p_ssha.digest() + salt + '' )
   8     return '%s%s' %( '{SSHA}', p_ssha_base64 )
   9 
  10 if __name__ == "__main__":
  11     print encode_SSHA_password ( 'secret', 'salt' )

• See: http://www.openldap.org/faq/data/cache/347.html

• or See LDAPUserFolder for zope project: SSH.py this code is better then me -- FrankieChow 2005-12-27 12:30:00

• It is a good idea. But If the wiki is live, How to upgrade it use this logic? The admin just know the user's sha1 password hash, not the clear text password. -- FrankieChow 2005-12-26 10:29:03

• I think it can do in here. in [moin-1.3 not moin-1.5]
  • MoinMoin/user.py

       1        #!python
       2        def _validatePassword(self, data):
       3            ...            
       4             # And match (require non empty enc_password)
       5             if enc_password and enc_password == data['enc_password']:
       6                 # User password match - replace the user password in the
       7                 # file with self.enc_password
       8                 data['enc_password'] = self.enc_password
       9                 return True, True
    

    -- FrankieChow 2005-12-27 13:29:03

• One option is to expire all passwords and requiring everyone to replace their password after the upgrade, which will create new safer password automatically.

1. Do not allow logging in with the hashed password. This would require changing the "forgotten password" functionality. Maybe it could send a special randomized "one-time password" that is accepted in addition to the regular password for a week or so and then expires. (Simply resetting the password and sending the user a new password would not be a good idea because other users could use this for deactivating the account of someone else until the others read their e-mail.)

   • I think MoinMoin can use the MoinMoinBugs/Cookie is not secure enough security_string to do this function. -- FrankieChow 2005-12-27 13:31:03

Of course, options two and three could also be combined.

I am sorry but I don't understand why it should be necessary to unencrypt the password of the user. It is much easier to take the uid from the data/user dir. If you use ?action=userform&uid=xxx.xxx.xxx you don't need a password to login as a user. -- ReimarBauer 2005-02-15 08:38:16

---

The uid login indeed works, but my assumption that user IDs were deterministic was fortunately wrong. That makes me wonder why I've got the same user id at two MoinMoin wikis. Could this be related to cookies and the fact that the two wikis are hosted on the same site? Should I look into this more thoroughly?

So back to this bug report. Maybe you were mistaking my intentions in filing this. What I was saying is that encrypting the password at all seems kind of pointless if the password is not needed for logging in. The fact that there is a second mechanism for logging in for people with wiki read access reinforces this argument rather than weakening it. To me, having the password stored in encrypted form gives the message: "Being able to read this is not good enough for logging in." This is, for example, how it works in Linux with /etc/passwd. Everybody can read the encrypted passwords, but that does not make them able to log in as that user.

• Because: not more people have supper power computer to cal it. -- FrankieChow 2005-12-27 13:33:00

Modern Linuxes use shadowed passwords as an additional security measure against dictionary attacks, but that's a separate issue.

Also consider the other issue mentioned above: If I use the same password for two MoinMoin wikis, then everyone who has read access to either of the wiki directories can pretend to be me on the other wiki. This is not obvious because passwords are stored in encrypted form.

• Not really. Please explain this in a more detailed way. -- AlexanderSchremmer 2005-02-15 17:25:17

  • Assume that my name is FooBar and I am using the same name and password on Wikis A and B. Assume further that you have read access to the files on Wiki A. On Wiki A, do:

    # cd /path/to/wiki/user
    # grep FooBar *
    12345.123.123:name=FooBar
    # grep password 12345.123.123
    enc_password={SHA}xyzzyxyzzyxyzzy

    On Wiki B, go to the login page and enter username FooBar and password {SHA}xyzzyxyzzyxyzzy.

    • Right. But nobody should have write access to the wikis besides root and MoinMoin.

      • Where in the above is any write access required? Perhaps you mean read access. Also, even root on Wiki A is not necessarily trusted on Wiki B.

• If you use apache to handle the MoinMoin request pass. then the user running the apache can see the userdir. ( In Debian: Maybe the www-data. )

• so if some user can write cgi in that apache handle's website. he can read it.

• If you care it. please see suEXEC -- FrankieChow 2005-12-27 13:34:00

This problem is true for all applications using plain-text passwords (and I agree that accepting hashes for login is nearly like using plain-text passwords).

• I suppose you mean "read access". Write access is not required. If your comment on access rights is the official opinion, then 770 is a questionable permission setting for the wiki files; I'd go for 700. What still bothers me is that root and MoinMoin on wiki A can log in as myself on wiki B. But apart from that, I think that we agree: With the title of the bug report, I wanted to indicate that encrypted passwords give the impression of providing a better security than plaintext passwords, when in fact they don't really do (or only in a very limited way -- reusing the password on other sites with are not MoinMoin wikis). In such a setting, it would be more honest to the user not to encrypt at all.

  • In fact, I mean r/w permissions Maybe we should think about setting the permissions 700.

If they weren't (option 1. above), at least I would know that this is a throwaway password I should not use on another wiki site. If encrypted passwords were less useful (options 2. or 3. above), then people with read or write access to the wiki directory could not get into my other account. People who can modify the actual MoinMoin implementation could of course add password fishing functionality, but this is a risk inherent in all web applications, and thus expected by the security-aware user. Making more sense now? -- MalteHelmert 2005-02-15 17:18:04

Lulling users in a false sense of security becomes most obvious for me when a user request Moin via the userpreferences form to sent him his account data. In the e-mail the password is stated in encrypted form and the user is asked to copy his password in the login form. One could think: the password is encrypted so that no other person listening to e-mail-traffic could find it out and then lock in. But that's lulling the users in a false sense of security: it does not make a difference whether the password in the mail is encrypted or not, you just have to do some copy and paste work form the e-mail to the lock in form to get locked in. I would prefer to have a plain text password here.

• Of course it makes a difference whether the password is plain or encrypted. If you put a plain password there, everybody only getting a quick glance at that mail will know your password. And as many people use the same password for multiple purposes, he will know your password for ALL those purposes. Neither of this is the case when we transmit the encrypted version. So, although it makes no difference for moin security, it IS different for security in general. -- ThomasWaldmann 2006-11-25 01:58:35

Yes. I agree on that. You are right: it does make indeed a difference. I haven't thought on the screen or archived email problem.. -- OliverSiemoneit 2006-11-25 19:28:08

I have to admit that I only understand half of this page, but it wouldn't be too hard to just disable using hashed password functionality and then send the user a reactivation link where they can change their password without knowing it. I would implement this by storing the reactivation secret into their userprofile and removing it again when they have used it. Thoughts? -- JohannesBerg 2007-04-03 12:53:29

• Yes, that's a clean and good strategy. The reactivation secret should also expire if not used, maybe after a day or a week. -- -- MalteHelmert 2007-04-03 12:57:03

I would also have to admit that I do not understand all of this page, but if there is going to be a change to how passwords are processed, I would suggest consideration be given to client side hashing. My paranoia includes the possibility that a dishonest web site operator may modify the moin code to unencrypt my password, save it, and later try to access my email account with my wiki password.

To create a new password, client side Javascript could be used to hash the user ID, password, and salt. The result is passed and stored on the server. To logon, a timestamp (or random number) is saved and sent with the logon form. Client-side Javascript hashes the user ID, password, and salt; and then hashes the result with the timestamp. The result is sent to the server. The server hashes the saved hash against the saved timestamp and compares the result against the incoming hashed password.

The benefit to the user is his password (raw or encrypted) never leaves his PC.

Should a user forget his password, a timestamp (or random number) is added to his user record and he is emailed a URL that is valid for a few hours. The URL enables the user to reset his password. -- RogerHaase 2008-09-16 16:28:44

There is no way you could keep a malicious web site admin from getting your password if you enter it in a form, in cleartext, on his site. He just needs to modify the code to log the form contents and he has all passwords he wants.

How would clientside hashing work? If it is done by javascript code you get from that site, you have exactly the same problem if the evil site admin modified that code. AFAIK there is no standardized "client side hashing" stuff as you describe it built-in the browser. If you know more, please tell.

Maybe openid solves that problem, then you only have to trust one site (and all other sites have to trust that site).

-- ThomasWaldmann 2008-09-16 19:01:53

I didn't explain it very well -- clicking the submit button triggers the Javascript function and the hashed result overwrites the password field before the form is sent. The truly paranoid may inspect the incoming form and Javascript code to see what will be sent. Because users tend to reuse passwords, there is an inherent weakness in sending (raw or) encrypted passwords to any site. There are very few web sites that do this - Yahoo used to do it for their email logon. I know because I looked at their code -- but only after reading some negative PR that said Yahoo did not use https for their email login. Yahoo now uses https. I think the old way was better. -- RogerHaase 2008-09-16 19:46:34

This sounds to me quite different to the original topic. I want to see a FR for that and a patch and some ideas what we can provide to one who has disabled javascript for security reasons. It is a bit a dilemma - you want noone inspire to use a password for his credit card on a login account but you assume if he did so it should not be dangerous. -- ReimarBauer 2008-09-16 21:02:45

• Although I feel client side password hashing is an alternate solution to the original bug described above, I created FeatureRequests/ClientSidePasswordHashing. -- RogerHaase 2008-10-10 21:58:08

Plan

• Priority:
• Assigned to:
• Status: In recent moin versions you can't log in with the hash key. A user can get a reactivation link where they can change their password and this expires after 12h.

CategoryMoinMoinBugFixed