It’s less about “my framework makes this inconvenient” and more intuitions along the lines of “don’t roll your own crypto”. The setup described above (that is now active on LW2) doesn’t change anything about the password verification process and basically just adds an additional processing step on the client, which ensures that I am not introducing any bugs into our authentication process, which strikes me as much more risky. The risk of accidentally introducing a bug in the authentication protocol strikes me as bigger than the risk of someone being able to impersonate a user if they somehow got access to the old password hashes, and so I am very hesitant to mess with any authentication protocols on a deeper level, and so am actually quite happy about how inconvenient our framework makes it to mess up something in that space.
The only private data you get access to are old drafts, none of the other private data is copied over (we might port over PMs at some later point in time, but that will take a while).
The now implemented solution is only vulnerable to someone having gotten access to the old LW1 password hashes, at which point you very likely already have access to the rest of the private data for the user (not guaranteed, but given that the old database was structured as a giant key-value store for all user data almost any vulnerability would have very likely exposed both). I do agree that as soon as you log in, we should strongly encourage the user to create a new password. I will try to implement that soon.
I do agree that as soon as you log in, we should strongly encourage the user to create a new password. I will try to implement that soon.
Was the “change password” page actually tested to work for users who have logged in with ‘legacy’ LW1 credentials? E.g. I notice that there’s a textfield asking for my ‘current’ password on that page, and I have no idea how that would interact with your solution. I also edited the ‘email’ field in my user options, expecting it to set a ‘recovery’ address, but I have no idea if that worked properly. (I didn’t get a ‘verification’ message at that email, whereas that happened right away when I added it on LW1.) All this makes me quite nervous about fiddling with my LW2 credentials at this time, either by ‘changing’ or ‘resetting’ them. I’d rather deal with a theoretically ‘insecure’ hashing function for a while.
Ah, thanks a lot for pointing this out. I only tested the password-reset functionality, and just realized that the change password thing doesn’t work as well. I quickly changed the password-change flow to accommodate the new changes. Will push in the next few hours.
Um, now there is a “reset password” link, but it does not work properly at least in my case. My recovery address from LW1 was not in the version of the database that was imported to Lesser Wrong, and apparently setting that address as an ‘email’ in the “edit account” page did not help, either—it is not seen by the “reset password” functionality as a recovery address associated with my user. Weird.
Um, yes I did? (The email does appear in my ‘account’ page, after all.) Anyway, this issue is not so critical to me that I need “real-time support” from the site devs or anything like that. I only really care to the extent that other users may be similarly affected (as seen, e.g. from recent discussions on LW1!). So if it turns out that this is not a generalized problem w/ the site that would also hit other people, I’d think it preferable to just wait until other work on LW2 is completed and perhaps revisit the issue at a later time.
Ah, sorry. I suggested pinging us on Intercom because it will make it easier to find out the source of the bug via real-time chat than here in the comments. I am unsure whether other users will have the same problem before I know what the source of the problem is.
Can you tell me what’s printed in your browser console when you press the reset button?
I might have the same problem—I managed to log in with my lw1 password, but failed to update the password.
(The user interface for changing password is confusing so I’m not sure if I’m following the correct procedure.)
Originally the “EMAIL” field in “Edit Account”-page was empty (even I had set the recovery email before the lw1 was shut down) and clicking the “RESET PASSWORD” caused popup “Must pass options.email”. I set the “EMAIL” field and pressed the SUBMIT-button. After that clicking the “RESET PASSWORD” in “Edit Account”-page caused popup “User not found” to appear. (Nothing appears in browser console.)
Trying to log in to greaterwrong with the lw1 password caused message “LessWrong 1.0 detected, legacy password salt attached” to appear and the Username and Password fields to be erased. Trying to log in again produced the same result. Trying to use greaterwrong’s reset password feature gave the same “User not found”-error.
Any progress on this? With the switchover from LW1 now imminent, I’ve looked at the LessWrong code on github a bit more and from a cursory review, it really does seem that the usecase or ‘flow’ of a user editing their own “recovery email” address is broken. The code calls the proper Meteor/Vulcan functions when creating a new user, and will in turn create new users when importing them for the first time from a legacy (LW1) database, but aside from that, there is no acknowledgement that Vulcan/Meteor has its own functions in the ‘account’-related packages for setting/updating these data. Did you test this user flow (even just in a test instance of the code) and verify that it can be used to set an email address that the “forgot password/reset password” will rely on?
Huh, apologies for not being available for ‘realtime chat’ then. I just tried this quickly with a JS console, but weirdly enough I don’t see any message when pressing that button—all I see is the usual error message “user not found” popping up in the browser webview (This is probably an issue on my end, though—I’m not really familiar with how the browser console works). What I do see (though in the network view, not quite in the console) is the info being updated when I submit the “edit account” form, and I notice that the resulting object has an “email” property with the desired address as a string. (However, from quickly perusing the Meteor source code, it looks like it has all sorts of specialized functions on the server side for creating/updating/setting ‘account email’ data—e.g. it seems to keep track of ‘verified’ status and to also support multiple emails per user. I wonder if the problem is that the “edit account” ‘flow’ is not resulting in these functions being called? Or perhaps it’s not providing data in the format they expect? Something to look into, perhaps. I’m not sure how LW2 itself changes what Meteor does by default here)
It’s less about “my framework makes this inconvenient” and more intuitions along the lines of “don’t roll your own crypto”. The setup described above (that is now active on LW2) doesn’t change anything about the password verification process and basically just adds an additional processing step on the client, which ensures that I am not introducing any bugs into our authentication process, which strikes me as much more risky. The risk of accidentally introducing a bug in the authentication protocol strikes me as bigger than the risk of someone being able to impersonate a user if they somehow got access to the old password hashes, and so I am very hesitant to mess with any authentication protocols on a deeper level, and so am actually quite happy about how inconvenient our framework makes it to mess up something in that space.
The only private data you get access to are old drafts, none of the other private data is copied over (we might port over PMs at some later point in time, but that will take a while).
The now implemented solution is only vulnerable to someone having gotten access to the old LW1 password hashes, at which point you very likely already have access to the rest of the private data for the user (not guaranteed, but given that the old database was structured as a giant key-value store for all user data almost any vulnerability would have very likely exposed both). I do agree that as soon as you log in, we should strongly encourage the user to create a new password. I will try to implement that soon.
Was the “change password” page actually tested to work for users who have logged in with ‘legacy’ LW1 credentials? E.g. I notice that there’s a textfield asking for my ‘current’ password on that page, and I have no idea how that would interact with your solution. I also edited the ‘email’ field in my user options, expecting it to set a ‘recovery’ address, but I have no idea if that worked properly. (I didn’t get a ‘verification’ message at that email, whereas that happened right away when I added it on LW1.) All this makes me quite nervous about fiddling with my LW2 credentials at this time, either by ‘changing’ or ‘resetting’ them. I’d rather deal with a theoretically ‘insecure’ hashing function for a while.
Ah, thanks a lot for pointing this out. I only tested the password-reset functionality, and just realized that the change password thing doesn’t work as well. I quickly changed the password-change flow to accommodate the new changes. Will push in the next few hours.
Um, now there is a “reset password” link, but it does not work properly at least in my case. My recovery address from LW1 was not in the version of the database that was imported to Lesser Wrong, and apparently setting that address as an ‘email’ in the “edit account” page did not help, either—it is not seen by the “reset password” functionality as a recovery address associated with my user. Weird.
Did you submit the form before you pressed the reset account button? Otherwise can you ping us on Intercom and I can debug it in detail.
Um, yes I did? (The email does appear in my ‘account’ page, after all.) Anyway, this issue is not so critical to me that I need “real-time support” from the site devs or anything like that. I only really care to the extent that other users may be similarly affected (as seen, e.g. from recent discussions on LW1!). So if it turns out that this is not a generalized problem w/ the site that would also hit other people, I’d think it preferable to just wait until other work on LW2 is completed and perhaps revisit the issue at a later time.
Ah, sorry. I suggested pinging us on Intercom because it will make it easier to find out the source of the bug via real-time chat than here in the comments. I am unsure whether other users will have the same problem before I know what the source of the problem is.
Can you tell me what’s printed in your browser console when you press the reset button?
I might have the same problem—I managed to log in with my lw1 password, but failed to update the password.
(The user interface for changing password is confusing so I’m not sure if I’m following the correct procedure.)
Originally the “EMAIL” field in “Edit Account”-page was empty (even I had set the recovery email before the lw1 was shut down) and clicking the “RESET PASSWORD” caused popup “Must pass options.email”. I set the “EMAIL” field and pressed the SUBMIT-button. After that clicking the “RESET PASSWORD” in “Edit Account”-page caused popup “User not found” to appear. (Nothing appears in browser console.)
Trying to log in to greaterwrong with the lw1 password caused message “LessWrong 1.0 detected, legacy password salt attached” to appear and the Username and Password fields to be erased. Trying to log in again produced the same result. Trying to use greaterwrong’s reset password feature gave the same “User not found”-error.
Any progress on this? With the switchover from LW1 now imminent, I’ve looked at the LessWrong code on github a bit more and from a cursory review, it really does seem that the usecase or ‘flow’ of a user editing their own “recovery email” address is broken. The code calls the proper Meteor/Vulcan functions when creating a new user, and will in turn create new users when importing them for the first time from a legacy (LW1) database, but aside from that, there is no acknowledgement that Vulcan/Meteor has its own functions in the ‘account’-related packages for setting/updating these data. Did you test this user flow (even just in a test instance of the code) and verify that it can be used to set an email address that the “forgot password/reset password” will rely on?
Huh, apologies for not being available for ‘realtime chat’ then. I just tried this quickly with a JS console, but weirdly enough I don’t see any message when pressing that button—all I see is the usual error message “user not found” popping up in the browser webview (This is probably an issue on my end, though—I’m not really familiar with how the browser console works). What I do see (though in the network view, not quite in the console) is the info being updated when I submit the “edit account” form, and I notice that the resulting object has an “email” property with the desired address as a string. (However, from quickly perusing the Meteor source code, it looks like it has all sorts of specialized functions on the server side for creating/updating/setting ‘account email’ data—e.g. it seems to keep track of ‘verified’ status and to also support multiple emails per user. I wonder if the problem is that the “edit account” ‘flow’ is not resulting in these functions being called? Or perhaps it’s not providing data in the format they expect? Something to look into, perhaps. I’m not sure how LW2 itself changes what Meteor does by default here)