Skip to main content
Topic: 38k Member Forum (Read 11406 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

38k Member Forum

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?
Bryan Deakin
Former Project Manager/Customiser/Marketing @ SMF

Re: 38k Member Forum

Reply #1

As far as I remember, they have a different encription, so I don't think it's possible at all...
~ SimplePortal Support Team ~

Re: 38k Member Forum

Reply #2

seen that being said for 2.1 but not 2.0 ( read all topics) also their must be an alternate route somewhere :)
Bryan Deakin
Former Project Manager/Customiser/Marketing @ SMF

Re: 38k Member Forum

Reply #3

I don't think you should have to reset the passwords. They should be updated by ElkArte as people login.

Re: 38k Member Forum

Reply #4

O.o how can it work at all with the old encryption?
~ SimplePortal Support Team ~

Re: 38k Member Forum

Reply #5

Quote from: Joshua Dickerson – I don't think you should have to reset the passwords. They should be updated by ElkArte as people login.
This.
Thorsten "TE" Eurich
------------------------

Re: 38k Member Forum

Reply #6

Quote from: Flavio93Zena (#OpIsis) – 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.

Re: 38k Member Forum

Reply #7

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.

Re: 38k Member Forum

Reply #8

Hi, I'm the guy with the 38K registered members. Thanks Runic for the iniciative to post my question!

Quote from: Spuds – 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). 
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?

Re: 38k Member Forum

Reply #9

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.

Re: 38k Member Forum

Reply #10

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.
Last Edit: March 16, 2016, 11:22:22 am by vkot

Re: 38k Member Forum

Reply #11

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
Bugs creator.
Features destroyer.
Template killer.

Re: 38k Member Forum

Reply #12

Quote from: vkot – Hi, I'm the guy with the 38K registered members. Thanks Runic for the iniciative to post my question!

Παρακαλώ (Your welcome for those that dont know Greek ;) )
Bryan Deakin
Former Project Manager/Customiser/Marketing @ SMF

Re: 38k Member Forum

Reply #13

Quote from: Spuds – 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.

Is there a reason it's this clunky? I'm going to have to fix this before converting E.

Re: 38k Member Forum

Reply #14

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".