Duplicate users/passwords?

[RDX1]

Would anyone be interested in writing a hack for finding duplicate users?

There was a hack written for this by checking the ip's and the passwords, and if two users matched it would so it.

[Zachery]

Would anyone be interested in writing a hack for finding duplicate users?

There was a hack written for this by checking the ip's and the passwords, and if two users matched it would so it.
it wouldnt be a hack so much as a serrious securty issue >.< removing the md5+salts would be the only way to check idential passwords i belive

[okrogius]

Hashing can remain with the same password checking, but unique user salts would indeed have to go.

[Zachery]

Hashing can remain with the same password checking, but salts would indeed have to go.
whichs brings up security issues.

now anyone who got the md5 from one site could use it on another vB with the same modifcation made

thus creating an insecure system...

[okrogius]

whichs brings up security issues.

now anyone who got the md5 from one site could use it on another vB with the same modifcation made

thus creating an insecure system...
There are no security issues created just by storing passwords even in plain text provided the server(s) is(/are) secured well, and the people who have access to the database are responsible. Granted that will probably not be the ideal aproach in most scenarios, by no way is it just insecure for that.

Whether or not these two (see first sentence) can be aplied to a typical vb user, noting especially how many vbulletins run on shared hosting, that is a whole different story. Do you want to remove an extra safety net in case your well versed technical co-admin places a db backup somewhere without any security (another random example why hashes are there, but note that it does not make not hasing any less secure, it's just significantly harder to "screw up" if the passwords are hashed)?

[RDX1]

I'm not asking to see the actual passwords, just the md5 hashes, so if the user has the same ip, and the same password i can assume it is a double user.

There was a hack made before for vb2, all i'm asking is for a vb3 version.

[RDX1]

<a href="https://vborg.vbsupport.ru/showthread.php?t=36269" target="_blank">https://vborg.vbsupport.ru/showthread.php?t=36269</a>

[NTLDR]

We know that ;) However the probability of two users with the same password actually having the same password hash (due to the salt) system is rather slim. This is where the difficulty lies.

[RDX1]

What's Salt?

And if it can't be done, then just the same ip would be fine.

[Zachery]

What's Salt?

And if it can't be done, then just the same ip would be fine.
the salt is what is generated to dlb encrypt the users password

md5+salt+password and each salt is random

[RDX1]

the salt is what is generated to dlb encrypt the users password

md5+salt+password and each salt is random
Well can you just have it check for duplicate ips?

[buro9]

I'm actually looking for the same thing, based on:

IP checking (Exact and ISP (guess) matching).
E-mail duplication.
IM info duplication.

I would also have liked similar passwords... it was the most successful method for spotting returning trolls in the past. I concede I don't care about salted passwords... Never had a problem here... but trolls are a concern, and any tool that can assist me in spotting returning trolls has a higher value to me than salted passwords.

Finally... I would like this as an additional function. Such that it can be used to populate the "new user registered at your forum" e-mail that admins receive, and can also be available via the admin control panel for retrospective searching (in case the data changes through new registrations ;)).

[Zachery]

i think in vB3 by default you can be emailed everytime theres a new user

[buro9]

i think in vB3 by default you can be emailed everytime theres a new user

Yes, we understand that.

What we are looking for is an improvement to that e-mail.

In VB2 I was running a hack that made those e-mails like this:


Board New Member Registration:

Nick : XXXXXXX
Password : PPPPPP
Email : EEEEEE
IP address: IP
Biography :
Location :
Interests :
Occupation :


HomePage : http://
Birthday : N/A

WHO MIGHT THIS NEW USER BE?
----------------------------
# | PROBABILITY | USER..| ID.|....EMAIL........|.MATCHES..................
-------------------------------------------------------------------------------------
1- 90% => XXXXXXX (id:NNNN) EEEEEE [password][IP]
2- 50% => XXXXXXX (id:NNNN) EEEEEE [password]
3- 50% => XXXXXXX (id:NNNN) EEEEEE [password]
4- 45% => XXXXXXX (id:NNNN) EEEEEE [IP]
5- 5% => XXXXXXX (id:NNNN) EEEEEE [ISP]

----------------------------
[email] => indicates user has the same email with this new user
[password] => indicates user has the same password with this new user
[IP] => indicates user has the same IP address with this new user
[ISP] => indicates user is from the same ISP with this new user. That is, their IP range is same. Eg. 195.100.200.XXX etc..


Check his profile at:
http://www.bowlie.com/forum/member.php?action=getinfo&userid=NNNN


Where:

XXXXXX = username
NNNN = userId
PPPP = password - Yes this is passed plain text... if you have matched on someones password you need to determine whether that password is unique or common... if the password was "password" then you'd know to ignore this test.
IP = user IP address
EEEEE = user email address

Thus, the admin (myself, and myself alone) was empowered to ban or watch a user based on their probability of being someone else... prior to their posting and sometimes even prior to their completing registration.

[RDX1]

Yes, we understand that.

What we are looking for is an improvement to that e-mail.

In VB2 I was running a hack that made those e-mails like this:



Where:

XXXXXX = username
NNNN = userId
PPPP = password - Yes this is passed plain text... if you have matched on someones password you need to determine whether that password is unique or common... if the password was "password" then you'd know to ignore this test.
IP = user IP address
EEEEE = user email address

Thus, the admin (myself, and myself alone) was empowered to ban or watch a user based on their probability of being someone else... prior to their posting and sometimes even prior to their completing registration.
Maybe you should make a new thread, might get more help, since there seems not to be any help here ;)

I might just have to modify the hack myself, i'm sure a few table changes would fix it ;)

[buro9]

Maybe you should make a new thread, might get more help, since there seems not to be any help here ;)

No need ;) Fewer threads is a nice goal.

Anyway... so I've done some searching and found the VB2 hack:

https://vborg.vbsupport.ru/showthread.php?t=38909

Which was by Logician.

I've PM'd him to ask him if he is either going to port his hack or permit his code to be tweaked slightly so that it is suitable for VB3.

I'm now awaiting a response on that :) He's cool though... and VB.org mod! Not sure when he got promoted... but very cool... he deserves it as his were some of the hacks I always looked out for.

I think I'm going to hack mine anyway... It looks likely that for me to use the vBulletin user tables as a source of single-sign-on across other applications (a wiki at the least) that I'll need at the least an unsalted md5 hash of a user password... and somewhat likely (due to the primitiveness) of things like Php-Wiki and mod_auth_mysql ( http://httpd.apache.org/docs/mod/mod_auth.html ) that I may personally take a step towards having plain text passwords in the database. So there's little to stop me implementing the hack above in either scenario since I already know I need less security in the DB stored details for me to offer single sign-on and integrated login over other apps.

[buro9]

OK, Logician has responded.

He is going to convert all of his VB2 hacks to VB3. So I shall not be releasing anything I put in place on my boards that is similar.

He is also aware of the password problem... and that some of us feel that it was the crucial part of the hack... but he will address those things when he starts the conversion.

So there we are... if we can just be patient it will come along... which is probably for the best as anything I would've undertaken would've been a bit messy ;)

Cheers

David K

[Tom1234]

Was this duplicate user passwd recognition system ever developed for vB3? I agree that many would give up the security of encryption salting in order to keep trolls out. This was very powerful in vB2.

[Link14716]

It's not going to happen since you'd have to forcibly rip out the salting system and then hose all the current passwords.

[Tom1234]

I haven't looked at the code, but you're saying that the code changes would be substantial to remove salting?

As far as hosing the passwords, I envisioned a script to convert all passwords to de-salted versions.

[buro9]

I haven't looked at the code, but you're saying that the code changes would be substantial to remove salting?

As far as hosing the passwords, I envisioned a script to convert all passwords to de-salted versions.
Tip:

Look at logicians VB2 hack... then look at the javascript for login on vb3, remove the line blanking the password box, add a column to the user table for the plain password, adjust the login php to store the plain password, implement the VB2 hack into the register.php file with changes as applicable to match the new table layout.

Not that I have done that myself of course.