If you want backwards compatibility, you could store a data variable together with the password describing the type of encryption used, and assume the current encryption if the data variable is not found.
That way, you could keep the encryption type in site.config, but ask users to change or re-set passwords using the old encryption at login. If you're worried about plaintext passwords, then perhaps a script to go through the logins and check the length of the passwords stored could be a solution. I believe most encryption algorythms give fixed length results, which are longer than the maximum length of the password, so this check should get them all. Does boltwire keep track of which version it was last used with? If so it would be simple to automate such scripts rather than, as it was last I used one, requiring the user to dl extra files and execute them himself. Finally, requiring a small number of users to reset their passwords shouldn't be a massive problem. Doesn't the "lost password" function work fairly well? If not, perhaps work should be done to make that work out of the box, perhaps some kind of one-time configuration wizard for admins. I imagine something that checks for the existance of certain site variables and only shows up if they are missing. Thus ends my 2 cents. On 6 Juli, 16:12, The Editor <[email protected]> wrote: > After examining an issue brought up on the list, I've come to the > conclusion it would be best to tighten up BoltWire's login system a > bit. > > There is a security vulnerability based on BoltWire's ability to store > passwords as either plaintext or encrypted. There is no easy way to > exploit it at this point, because of other safeguards in place, but > our best bet is to have each level as secure as possible. Fortunately, > the fix is easy, and elegant. > > But it could affect some sites. Specifically if you have some members > with encrypted passwords and some without, one group or the other will > be excluded. And there's no easy way to solve this other than to > upgrade all passwords to one or the other format... Could be a > challenging problem... > > Anyway, I'm just curious how many people this might affect? It should > only affect you if you have at some point used the loginfmt = > plaintext option in your register form, and then, only for some of > your login accounts, not all... > > The other thing I'm wondering, is if we shouldn't change how the > encryption key is set. Right now, it's a value defined in site.config, > but that almost invites people to change it, when it should never be > changed once a site is rolling. A better solution might be to set it > as a value in index.php, and tell people never to touch it only once > at their initial installation. > > Another option is not make this change until we get to 4.xx. I think > I'm pretty much done with 3.xx, so we could build this into the change > for 4.xx. It is the right fix, but it could be a massive problem for a > small number of users. Hopefully none... Feedback on how to proceed > is appreciated... > > Cheers, > Dan -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
