JSPWiki
  1. JSPWiki
  2. JSPWIKI-159

Getting an new password is only possible for one user per mail address

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      If there's more than one user with a given email address, it's only possible for one of these users to get a new password via email.

        Activity

        Hide
        Andrew Jaquith added a comment -

        Well, you shouldn't be creating more than one account per e-mail, should you?

        Seriously, this is why sites like Amazon use your e-mail address as your login identifier.

        I am tempted to close this as a "won't fix," but that's probably a bit harsh. Frankly, I have no idea what we should do here. Reset them all at once, maybe?

        Show
        Andrew Jaquith added a comment - Well, you shouldn't be creating more than one account per e-mail, should you? Seriously, this is why sites like Amazon use your e-mail address as your login identifier. I am tempted to close this as a "won't fix," but that's probably a bit harsh. Frankly, I have no idea what we should do here. Reset them all at once, maybe?
        Hide
        florian1978 added a comment -

        I don't agree with your first statement. As long as it isn't a limitation that is explicitly told to the user (and handled during user creation - "error: a user with your mail address already exists") there's no reason why one mail address shouldn't be used in several accounts.
        I could list several people I know of who are sharing a mail address... older people, families, ...
        Resetting them all at once could be one solution, listing them and let the user choose which one to reset another one. The simple way (I guess) would be ensuring the 1:1 relationship you're presuming. This would have to happen not ony during user creation but also on changing a profile.
        So, "won't fix" is no solution, you'll have to decide which way to go.

        Show
        florian1978 added a comment - I don't agree with your first statement. As long as it isn't a limitation that is explicitly told to the user (and handled during user creation - "error: a user with your mail address already exists") there's no reason why one mail address shouldn't be used in several accounts. I could list several people I know of who are sharing a mail address... older people, families, ... Resetting them all at once could be one solution, listing them and let the user choose which one to reset another one. The simple way (I guess) would be ensuring the 1:1 relationship you're presuming. This would have to happen not ony during user creation but also on changing a profile. So, "won't fix" is no solution, you'll have to decide which way to go.
        Hide
        Janne Jalkanen added a comment -

        I think resetting them all makes sense. Displaying the user information about user accounts sounds... fishy in the security point of view.

        This isn't very urgent IMO though.

        Show
        Janne Jalkanen added a comment - I think resetting them all makes sense. Displaying the user information about user accounts sounds... fishy in the security point of view. This isn't very urgent IMO though.
        Hide
        Janne Jalkanen added a comment -

        What are the security implications of allowing multiple people with the same email address? Can I get any advantage by registering using someone else's email address?

        Show
        Janne Jalkanen added a comment - What are the security implications of allowing multiple people with the same email address? Can I get any advantage by registering using someone else's email address?
        Hide
        florian1978 added a comment -

        What are the security implications of allowing multiple people with the same email address?

        Well, one could change another users' passwords. However, from the social point of view, I don't think there are any security implications. Using the same email address means trusting one another in all related things.

        Can I get any advantage by registering using someone else's email address?

        In which way has this got to do with the issue? You can do this already, and you'll be able to do this in the future, too, no matter how this issue will be handled.

        AFAIK, JSPWiki is lacking a double opt in solution anyway, meaning it's not verified whether a provided mail address really belongs to a user.

        Show
        florian1978 added a comment - What are the security implications of allowing multiple people with the same email address? Well, one could change another users' passwords. However, from the social point of view, I don't think there are any security implications. Using the same email address means trusting one another in all related things. Can I get any advantage by registering using someone else's email address? In which way has this got to do with the issue? You can do this already, and you'll be able to do this in the future, too, no matter how this issue will be handled. AFAIK, JSPWiki is lacking a double opt in solution anyway, meaning it's not verified whether a provided mail address really belongs to a user.
        Hide
        Janne Jalkanen added a comment -

        I think verification of the email might be a really good thing to add... That would cut down on a lot of spambots.

        Show
        Janne Jalkanen added a comment - I think verification of the email might be a really good thing to add... That would cut down on a lot of spambots.
        Hide
        Janne Jalkanen added a comment -

        BTW, one thing about this is that some spambots try to register with the same email addresses all the time - just because they can. So it is a sort of a security problem.

        Show
        Janne Jalkanen added a comment - BTW, one thing about this is that some spambots try to register with the same email addresses all the time - just because they can. So it is a sort of a security problem.
        Hide
        Andrew Jaquith added a comment -

        Let's get some consensus on this... in the UserManager/Database code, we already check to see if a user login name/wikiname/full name conflicts with another in the database, and prohibit creation if there is a collision.

        I'd like to suggest we adopt the strategy of "one user, one e-mail." In essence, we would prohibit users from registering more than one user ID per e-mail address.

        Show
        Andrew Jaquith added a comment - Let's get some consensus on this... in the UserManager/Database code, we already check to see if a user login name/wikiname/full name conflicts with another in the database, and prohibit creation if there is a collision. I'd like to suggest we adopt the strategy of "one user, one e-mail." In essence, we would prohibit users from registering more than one user ID per e-mail address.
        Hide
        florian1978 added a comment -

        I'd like to suggest we adopt the strategy of "one user, one e-mail." In essence, we would prohibit users from registering more than one user ID per e-mail address.

        That's a valid approach and probably the one which causes least work and confusion

        Show
        florian1978 added a comment - I'd like to suggest we adopt the strategy of "one user, one e-mail." In essence, we would prohibit users from registering more than one user ID per e-mail address. That's a valid approach and probably the one which causes least work and confusion
        Hide
        Janne Jalkanen added a comment -

        I'm +0 on this... On the other hand, it simplifies things. On the other hand, it means that it's possible to figure out who already has an account in the system.

        Show
        Janne Jalkanen added a comment - I'm +0 on this... On the other hand, it simplifies things. On the other hand, it means that it's possible to figure out who already has an account in the system.
        Hide
        Carl Hagenmaier added a comment -

        Gee, why not just have the user request a password reset using his/her login rather than his/her email address? Uniqueness of the login is already enforced, and it seems like the natural thing anyway. (I can never remember which of my umteen email aliases I use to sign up, but somehow manage to remember my login

        If there's agreement on this solution, I'll be glad to implement it.

        Show
        Carl Hagenmaier added a comment - Gee, why not just have the user request a password reset using his/her login rather than his/her email address? Uniqueness of the login is already enforced, and it seems like the natural thing anyway. (I can never remember which of my umteen email aliases I use to sign up, but somehow manage to remember my login If there's agreement on this solution, I'll be glad to implement it.
        Hide
        Janne Jalkanen added a comment -

        Allowing login credentials for password recovery is a problem, since that means that you could be subjected to a denial-of-service attack. Say, have a bot reset your password every few minutes.

        The name with which you edit the wiki pages is visible in every page edit... Also, changing your email address is probably easier than abandoning your account and starting again.

        Show
        Janne Jalkanen added a comment - Allowing login credentials for password recovery is a problem, since that means that you could be subjected to a denial-of-service attack. Say, have a bot reset your password every few minutes. The name with which you edit the wiki pages is visible in every page edit... Also, changing your email address is probably easier than abandoning your account and starting again.
        Hide
        Carl Hagenmaier added a comment -

        I think the wikiName rather than the loginName is displayed in the edit history. At least that's how my local wiki seems to behave.

        A user "record" has seven variables, four of which are relevant here:
        loginName, e.g., "carl"
        wikiName, e.g., "CarlHagenmaier"
        fullName, e.g., "Carl Hagenmaier"
        email, e.g., "carl@xxxx.com"

        A user profile has three of these, omitting the wikiName, which is algorithmically generated from the fullName.

        Let's see if we can reverse engineer where each is used (and please correct me where I don't have this correct):

        loginName-- used for login; can be used in group definition and ACL; displayed only in profile and not visible to other users
        wikiName--can be used in group definition and ACL; displayed in lots of places and visible to other users (e.g., page history)
        fullName--can be used in group definition and ACL; displayed only in profile and not visible to other users
        email-- displayed only in profile and not visible to other users

        I would propose the following:

        Login credentials must be unique, not public. They should be used for login, profile management (including password reset), and any other activity related to user identity.

        Display names must be unique and public. They should be used for group management and ACL but not for login, profile management, etc.

        Show
        Carl Hagenmaier added a comment - I think the wikiName rather than the loginName is displayed in the edit history. At least that's how my local wiki seems to behave. A user "record" has seven variables, four of which are relevant here: loginName, e.g., "carl" wikiName, e.g., "CarlHagenmaier" fullName, e.g., "Carl Hagenmaier" email, e.g., "carl@xxxx.com" A user profile has three of these, omitting the wikiName, which is algorithmically generated from the fullName. Let's see if we can reverse engineer where each is used (and please correct me where I don't have this correct): loginName-- used for login; can be used in group definition and ACL; displayed only in profile and not visible to other users wikiName--can be used in group definition and ACL; displayed in lots of places and visible to other users (e.g., page history) fullName--can be used in group definition and ACL; displayed only in profile and not visible to other users email-- displayed only in profile and not visible to other users I would propose the following: Login credentials must be unique, not public. They should be used for login, profile management (including password reset), and any other activity related to user identity. Display names must be unique and public. They should be used for group management and ACL but not for login, profile management, etc.
        Hide
        Stefan Bohn added a comment -

        Janne
        "Allowing login credentials for password recovery is a problem, since that means that you could be subjected to a denial-of-service attack. Say, have a bot reset your password every few minutes."

        Like other sites, we could first send an email with a (temporary?) link to confirm the change request. Then the user has to follow the link to change the password.

        Show
        Stefan Bohn added a comment - Janne "Allowing login credentials for password recovery is a problem, since that means that you could be subjected to a denial-of-service attack. Say, have a bot reset your password every few minutes." Like other sites, we could first send an email with a (temporary?) link to confirm the change request. Then the user has to follow the link to change the password.
        Hide
        Glen Mazza added a comment -

        Should we rename this Wiki issue to "Prohibit more than one user from sharing the same email address?" (Sounds like a good idea to me.) I think that's what all the other Wikis do, even if it lets a hacker know that a certain email address is already registered (If that's a concern to anyone, they can create a throwaway hotmail or gmail account when they register.)

        Show
        Glen Mazza added a comment - Should we rename this Wiki issue to "Prohibit more than one user from sharing the same email address?" (Sounds like a good idea to me.) I think that's what all the other Wikis do, even if it lets a hacker know that a certain email address is already registered (If that's a concern to anyone, they can create a throwaway hotmail or gmail account when they register.)
        Hide
        Florian Holeczek added a comment -

        Hmm... When opening this issue, I've been chosing this subject intentionally, because it just describes a concrete problem which arises from the current design. There has been some discussion so far, shedding light on several aspects. A simple rename seems too simple to me, what about creating the following sub-tasks:

        • Ensure 1:1 relationship between loginName and email address
          This includes updating documentation, with special regards to the different *Names' meanings and behaviours.
          Probably this is also a point for the ReleaseNotes, because existing user databases have to be adapted when updating. It's also a candidate for linking to JSPWIKI-130 .
        • Define and implement improved signup, password reset and email address change workflows
          Important constraints are: double checks (double opt-in) for every action, prevent DoS attacks against both existing users and the JSPWiki instance, minimize exposure to bots
          For example:
          Signup: send a verification mail with a link that has to be followed in order to finish signup
          Password Reset: Which are the prerequisites to provide for initiation - loginName, email address, both? Afterwards, send a verification mail with a link that has to be followed in order to get a newly generated password by mail.
          Email Address Change: send a verification mail with a link that has to be followed in order to finish the change
          Again, this includes updating documentation.
        Show
        Florian Holeczek added a comment - Hmm... When opening this issue, I've been chosing this subject intentionally, because it just describes a concrete problem which arises from the current design. There has been some discussion so far, shedding light on several aspects. A simple rename seems too simple to me, what about creating the following sub-tasks: Ensure 1:1 relationship between loginName and email address This includes updating documentation, with special regards to the different *Names' meanings and behaviours. Probably this is also a point for the ReleaseNotes, because existing user databases have to be adapted when updating. It's also a candidate for linking to JSPWIKI-130 . Define and implement improved signup, password reset and email address change workflows Important constraints are: double checks (double opt-in) for every action, prevent DoS attacks against both existing users and the JSPWiki instance, minimize exposure to bots For example: Signup: send a verification mail with a link that has to be followed in order to finish signup Password Reset: Which are the prerequisites to provide for initiation - loginName, email address, both? Afterwards, send a verification mail with a link that has to be followed in order to get a newly generated password by mail. Email Address Change: send a verification mail with a link that has to be followed in order to finish the change Again, this includes updating documentation.
        Hide
        Glen Mazza added a comment -

        Hi Florian. Whether the subsequent matters in the second bullet (all good ideas, BTW) are put in subtasks under this JIRA item, or placed into one or more new JIRAs with a dependency on this one, either is fine IMO. But I still don't like the title "Getting a new password is only possible for one user per mail address" because consensus was reached that we shouldn't have the same email address shared with multiple accounts, while its titling still gives the indication that we've haven't reached that consensus yet. This then forces would-be patch submitters to have to read a long comments section to try to figure out what the consensus was. It's kind of like having a JIRA item titled "My Mother is unhappy with the color scheme of the application", once consensus to the solution is reached the JIRA item should be renamed to that consensus ("Change to a red and white background", for example.) Crisply titled JIRAs giving a specific task encourage patch submitters much more than fuzzy, ambiguous ones.

        Show
        Glen Mazza added a comment - Hi Florian. Whether the subsequent matters in the second bullet (all good ideas, BTW) are put in subtasks under this JIRA item, or placed into one or more new JIRAs with a dependency on this one, either is fine IMO. But I still don't like the title "Getting a new password is only possible for one user per mail address" because consensus was reached that we shouldn't have the same email address shared with multiple accounts, while its titling still gives the indication that we've haven't reached that consensus yet. This then forces would-be patch submitters to have to read a long comments section to try to figure out what the consensus was. It's kind of like having a JIRA item titled "My Mother is unhappy with the color scheme of the application", once consensus to the solution is reached the JIRA item should be renamed to that consensus ("Change to a red and white background", for example.) Crisply titled JIRAs giving a specific task encourage patch submitters much more than fuzzy, ambiguous ones.
        Hide
        Florian Holeczek added a comment -

        OK, looking at it from this point of view, I agree!

        Show
        Florian Holeczek added a comment - OK, looking at it from this point of view, I agree!

          People

          • Assignee:
            Unassigned
            Reporter:
            Florian Holeczek
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development