A friend is wanting to move his forum has 38k active members and he is worried that converting direct from SMF, so I said I would ask this for him, if he would use the 2.0 converter would his members still need to reset passwords, as it is done on 2.1? If so is their a route you can think off that will save his passwords?
As far as I remember, they have a different encription, so I don't think it's possible at all...
seen that being said for 2.1 but not 2.0 ( read all topics) also their must be an alternate route somewhere :)
I don't think you should have to reset the passwords. They should be updated by ElkArte as people login.
O.o how can it work at all with the old encryption?
When you login it first checks the ElkArte hash. If that doesn't match, then it tries other strategies until it gets one that matches. It had a bunch of strategies.
You'll still have to login again.
Be sure "Allow password hash conversion" is checked, its under Admin->Configuration->Security/Moderation->General Its intended to help this issue when sites are converted
Then (to recap what others already said)
A user will attempt login, it will look liked it failed and ask for their password again, at that point it will log them in (assuming of course the password was right).
After they successfully login, the old password hash will be converted to the new (industry standard) hashing.
Hi, I'm the guy with the 38K registered members. Thanks Runic for the iniciative to post my question!
In this case, it seems simple enough.
Is it also that simple for the people that have stored their password on the browser? They will just click the "Log in" button a second time and they will enter, or they'll have to type their password again somewhere else?
I don't think the stored passwords / autofill will work (not 100% sure though).
Likely they will need to use the keyboard on both screens. Those autofills look for matching form names/ids and they are likely not the same between your current platform and ElkArte.
It would be a small nuisance for those that forgot their password, they would have to reset it.
But what about those that have changed their email account and haven't updated their forum info with the new email and don't have access to their old email account anymore? It would be impossible to reset their password. They would have to message me outside the forum and I have to trust that they are who they say they are and then reset their password manually.
I suppose the login can be changed to always use the fallback and never update the password.
Of course it has drawbacks: 1) security, 2) security.
1) if the database is stolen, the hackers will be able to log in as any of your members without even knowing the password,
2) if your users do not know their password, they do not even know if they have reused it anywhere else and as such are more vulnerable to social engineering attacks and password theft.
@Spuds wouldn't be possible (theoretically, not that I have any plan to implement it), to attach some javascript to the login form, encrypt the password "SMF-like" and use this hash as the actual password passed to Elk's encryption js code and then to the server?
Let's illustrate it a bit. :P
Currently:
- user types password,
- Elk-js encrypts password
- Elk sends to server,
- server adds its hashing to the db password and compares to the hash from 2
While, what I'm describing is:
- user types password,
- Elk-js-mimic-SMF encrypt the password as sha1(something) (the same algorithm used by SMF),
- Elk-js encrypts what is coming from 2 the same as if it was user-typed password in the currently used method,
- Elk sends to server,
- server adds its hashing to the db password and compares to the hash from 3
Παρακαλώ (Your welcome for those that dont know Greek ;) )
Is there a reason it's this clunky? I'm going to have to fix this before converting E.
Because the form sends an encrypted password on the first pass, which the site then does a validation against. Once the site knows the password is valid, to one of the many hashing algorithms, it resets the form such so that it returns the password to the server in plain text. The plain text password is (assuming it once again validates) used to create the new style db hash. You could eliminate the form login encryption and make the conversion less "clunky".
Or activate the session and require a password confirmation (just to make it clear).
When inflicting change on a hundred thousand people, it is wise to make it go as smoothly as possible >_>
Just my 0.02, but I think that stressing it so much about re-typing a password is... Really, really overkill.
@Vekseid what do you mean with "activate the session"?
If it is what I think it could be you'd have to basically maintain the two systems in parallel and use the one used by the member.
I think that, if you really want to avoid any hassle, it would be easier to just drop the migration of the passwords to the new encryption and continue to use the old one.
It's probably the only way that will ensure nobody is going to have to type the password again.
You have to decide which is the trade-off: if you are sure members will not know their password and will have a broken email, then rely on the volatility of a cookie is your only option to make all of them happy. :)
I understand why they'll have to type the password in a second time, it's mostly just a wording change.
So, there is an (easy) way to keep the old passwords and the old encryption? There is an option somewhere in the migration process?
If I choose to do this, can I (easily) change to the new encryption at a later time?
I am thinking if there is really a big and serious reason to change to the new encryption. How unsafe is the old one? I mean, it΄s not like passwords in plain text. And we have been using this system for almost 15 years... (since the YaBBSE days...)
The old one has issues but I'm not sure if the new one is any better, I haven't looked at it.
The main issue with the old password hash was, basically if a forum database was compromised, the saved hash could be used to login to the system ... you did not even need to know what the original password was,
If a someone used the same password on other sites (with the same forum software), they could use the hash to login there as well. So your site may be secure, but you were still vulnerable to all other similar sites, and although the original user password was "safe" it did not matter anyway.
With some edits I believe you can have the old work on the new, have not really thought about that, but you did give up some level of security as discussed.
I know how it works in SMF.
What I was doing for my own custom CMS was to have both the client and server perform some of the hashing work - with the client doing most of it. The client would do sha512 256 times, and send the 255th and 256th hash to the server in base64 (88 characters).
The server would verify the client had hashed correctly, then hash the 256th hash a few more times (along with a salt) before storing/checking the database.
This IMO gives the best of all possible worlds
- It can allow any size of password, it only ever arrives at the server as 88 characters
- This is one of those rare situations where we can verify client-side crypto.
- No more username salt nonsense
- Offloads some cpu cycles to the client.
- Still not sent over the wire in plaintext.
- Still hashed on the server, so getting the database doesn't get you any closer.
Is what I would like to see, personally.
Keep in mind that it should always work with JS disabled or absent.
What follows is a comprehensive list of the sorts of people who visit my site without functional javascript:
1) Spammers
2) Scrapers
3) People who have it disabled via noscript and can trivially enable it for my domain
4) More scrapers
5) More spammers
So no. It is perfectly valid to require functional javascript from people who wish to log in.
/insert snarky reply about a comprehensive list of uses for Javascript
I wonder if you actually checked your statistics before making that statement. You just might be surprised. I looked at my statistics, and their sheer variety managed to do just that. On my forum the most popular browsers in March were (in order) Firefox, various Chrome derivatives, Otter, Opera/Presto, K-Meleon, w3m and ELinks. That's trailed by e.g. Internet Explorer (at a still respectable ~9%), while Edge doesn't even make the top 10. Linux use (not including Android) is 16.1% and BSD is at 1.2%. And keep in mind that bots use a user agent that says Windows with either Firefox or Chrome, so in real terms much of that is likely significantly higher.
Yes, my forum is atypical. But most of us care deeply about this kind of thing. It's why I selected SMF and I've had plenty of positive feedback about how well it works with Javascript disabled and how well it works in older, alternative, and text browsers. Sure, we could trivially open another browser instead of Links2 or Netsurf. Yes, we could trivially enable Javascript. So what? We can also trivially close a site that's broken by design. Would your solution even work with screen readers? In short, know your audience. ElkArte's audience is obviously a lot wider than my audience, but it isn't synonymous with your audience either.
PS Regarding using Javascript to keep out bots, for that purpose it wouldn't make much sense to require it on every login. Requiring JS on the registration page would have the same effect — or lack thereof, depending on the sophistication of the bot. And come to think of it, I think my users may well be a lot more sympathetic to "please enable Javascript to register (this helps keep out bots)" than to "please enable Javascript to login."
Most of user-facing parts of Elk work without javascript. IIRC, the only "big" feature that require JS by design is the likes, anything else should pretty much work.
I the admin panel there are some pages that may have problems if JS is disabled, since the general consensus has been is acceptable to require JS in the admin panel (and some moderation functions).
You could, you know, just ask. I have dozens of blind members using a variety of screen readers. Yes, they parse javascript, have for decades. Can even read the ajax chat. They will be actively testing the Elkarte 1.1 betas for us. One uses JAWS even. : )
JAWS is important because it tries to outsmart the web designer. >_>
And if you want to see what useragents are bots, swapout your login url. Enjoy. Have not done this in years, but long story short I dropped IE6 support for Elliquiy when I realized every single IE6 user attempting to sign into my forums for the past year was a bot. 98% of the remaining bots were IE7-9. A handful of Firefox 3 & 3.5.
True, 'know your audience' is a thing. I had one lynx user for awhile - he was very vocal about it. I actually had a very simular argument with him.
Fact is, if you want to actually make an account and log in, I don't feel it is too much to ask for you to spare a few cycles to help secure your own password. If you are competent enough to know how to selectively disable/enable javascript, that should not be that much of a leap to understand why.
Ultimately, my forums are writing forums. My members have a reasonable level of sophistication - many use Linux, even - but they don't subject themselves to browsing from the console for the most part. They are there to read and write with each other.
And yeah, SMF working without javascript was a part of what drew me back in 2005. Now? Now I want the interface out of everyone's way. SMF/Elkarte is due for a colossal refactoring, from multiple angles.
Cool.
NB I never said I was opposed to adding extra security, merely that I was opposed to purposefully breaking things with JS disabled. Obviously, from a security standpoint the addition of Javascript does eliminate most potential sniffing dangers. From the top of my head, the only attack I can think of is that someone in the position to sniff may also be in the position to alter or block the JS sent to the user so that they get a nice unhashed password, but that would take more effort. Encryption would guard against the latter possibility, but in that scenario you probably wouldn't gain much from hashed passwords in the first place. (Correct me if I'm wrong.)
What I meant to imply when I called for us to "keep in mind that it should
always work with JS disabled or absent" is a warning message, for example:
<strong class="noJS">Warning: with Javascript disabled your password may be at greater risk of being sniffed by some script kiddie and/or the NSA.</strong>
coupled with, e.g.
$('.noJS').css('display', 'none'); // or however one might accomplish that in jQuery
And of course in my proposal you'd also flip the switch on a hidden INPUT element indicating whether or not the password comes prehashed.
Note that a warning or error message along those lines is a necessity regardless whether or not JS-less logins are supported. Javascript may have failed to load even when enabled because it was filtered by a proxy/firewall/malicious entity. As such, in a JS-only scenario there should be no forms on the page to prevent any accidental submissions. To prevent the layout from breaking you could just clone the children of a relevant DIV inside a newly created FORM element.
Well, it stops heartbleed-like sniffing, for example, as well as firesheep.
More pertinent is that by having the client do most of the hashing, you reduce some of the attack footprints against you (you still need to hash, of course, but still). No million-character passwords (an attack against Django for a time), no repeated login attempts eating up cpu cycles, etc.
In my Phoenix implementation it loads the login form in Javscript, yes, displaying a notice if not ('You need javascript in order to sign in or register') - the idea there being that a user should not have to even reload the page to login.
The Django issue was "simply" there was no limit to the password length (server-side), so you could send an arbitrary long password to the server, it would have to hash it requiring CPU-cycles. Of course, the longer the password, the harder is the hashing, so using a password in the realm of millions of characters would lead to a (D)DoS attack.
Using SHA\d+ the password is a fixed length, so you don't have to set a limit on the password length: if the hash passed to the server is not the expected length you send back to the client a NAY answer without even starting the server-side hashing.
That said, Elk enforces a max-length for the password (see your link), so it is less of a problem except for the few that would like to use a 64+ chars password and no javascript.
Yes, but although you repeated so at the end I just want to emphasize that as far as I can see, the difference between <= and == is a distinction without meaning. Either there's the potential for a DoS attack through extremely expensive computations or there isn't. Anything client-side does nothing to obviate that.