Can Moderators and Administrators read PM's?

[naughty]

I look at it this way... I dont want you digging into my PM's, so I would do you the same courtesy unless someone made it so I couldnt ignore them. (Making them public for the entire board)

 

[B_big dirigible]

My my, just about everything is sitting somewhere on the Internet, just waiting to be found.

SHA1search

can do hashes and reverse hashes in sha1 and md5 hashing algorithms, two of the popular ones. It shows that the example I posted, 098f6bcd4621d373cade4e832627b4f6, is the hash of test in md5.

That means that, contrary to popular belief, a site admin with access to the database can indeed determine a real password from the hashed version. That in turn means that he can log in as any user and read PMs (after some effort expended in rooting around inside the database, then using the converter to get the real password from its hashed version - on my board, in phpBB, the appropriate algorithm is md5, but there are a lot of hashing algorithms and other fora might used different ones).

Note that, as before, this is not possible at forum administrator or moderator levels. The site owner - the guy with the FTP passwords and access to the site's control panel functions (cPanel, Helm, Plesk, etc - shell access isn't needed) can get passwords. It looks like not even vBulletin SuperAdmin is high enough to do it.

Very interesting, albeit a bit tedious.

edit - No, don't need that FTP stuff, just access to the control panel. That's a different password, set by the site admin or owner.

 

[HazelGod]

I assume it encrypts then stores the password as plain text then decrypts to authenticate, that's the easier, more normal path?

No, in a normal application, the plaintext password is never stored. When a user creates a password, it is encrypted (typically with an industry standard algorithm like SHA1 or MD5) and that value is what gets stored.

When the user logs on and types in their password, the application uses the same algorithm to hash the text they enter and compares the result of that operation to the stored value for that user. Due to the mathematical complexity of the standard hash algorithms, the likelihood of two different character strings (passwords) creating the same hash value is infinitesimal...to the point of being negligible.

The nature of hash algorithms is also such that the forward operation (encrypting plaintext) is quite simple and requires little processing power. The reverse operation, however, is incredibly difficult, meaning it would require an enormous amount of time and processing power to retrieve the original text from any given hash

My my, just about everything is sitting somewhere on the Internet, just waiting to be found.

SHA1search

can do hashes and reverse hashes in sha1 and md5 hashing algorithms, two of the popular ones. It shows that the example I posted, 098f6bcd4621d373cade4e832627b4f6, is the hash of test in md5.

So how to explain this? Simple...weak passwords. These "search" applications use pre-compiled hash tables to find the original value. Basically, it's a big-ass dictionary of words along with their SHA1 and/or MD5 hash values. If the hash value you enter is in the table, then it just looks up the word that created that hash. This is why you should create strong passwords to protect sensitive accounts...like this one:
Em=ZaEaGr|oOatLI

 

[dong20]

No, in a normal application, the plaintext password is never stored. When a user creates a password, it is encrypted (typically with an industry standard algorithm like SHA1 or MD5) and that value is what gets stored.

"I assume it encrypts then stores the password as plain text then decrypts to authenticate, that's the easier, more normal path?"


Yes, that's what I said, a crypt of the password is created and stored but as 'plain text' i.e. ASCII characters which in most cases is visible as such. I didn't say the password was stored as it's seen by the user, although that's common enough.


Unless the table/field itself is encrypted so as to prevent directly viewing its contents at all (rare but does happen) then extracting the crypt is easy enough but won't be of any use without a means to decrypt it. Sometimes the contents are shown by symbols but that's usually just a cosmetic trick.


Still, it was very late when I wrote the above and I was tired so perhaps I didn't express my thoughts as clearly as I meant to. As I also went on to say it's then decrypted for authentication.

When the user logs on and types in their password, the application uses the same algorithm to hash the text they enter and compares the result of that operation to the stored value for that user. Due to the mathematical complexity of the standard hash algorithms, the likelihood of two different character strings (passwords) creating the same hash value is infinitesimal...to the point of being negligible.

In much the same way NTLM authentication (for example) doesn't pass the actual password. IN database terms, unless the table has a constraint on the password field (and why would it?) then it wouldn't matter if the resultant crypt wasn't unique though.

As for the risk of different inputs creating the same hash being infinitesmal (collisions), read on.

IN practical terms it's very very unlikely to occur but MD5 is prone to them. It is a fundemental weakness of MD5 and upset a few folk back in 2004! Collisions can be revealed in a few minutes, certainly less than an hour on any decent desktop PC. The source code to this is freely available online. SHA-1 etc aren't immune to this phenonemon of course but the more bits in the key the less likely it will ever happen in reality of course.

The nature of hash algorithms is also such that the forward operation (encrypting plaintext) is quite simple and requires little processing power. The reverse operation, however, is incredibly difficult, meaning it would require an enormous amount of time and processing power to retrieve the original text from any given hash

Depending on cipher strength and other factors of course, with SHA-1 being the more secure (if less popular because it's slower) of the two you mentioned. 3DES is OK too, but because of it's linear nature is better suited to a hardware implementation and is in decline, though it remains popular with VPNs etc. Many proprietory systems use a made up key and a crypt()/decrypt() function. The key may have just a few bits. No use for banking but it works fine for most uses, forums etc. I'm not saying LPSG does this, but I know several that do or did.

As as aside, as I said above MD5 has some fundemental flaws (it's collision 'prone' for one) - though that risk can be somewhat mitigated. It's use must now be questioned where security is actually important.Still, in most cases MD5 is perfectly fine, and it's still a 'standard' with SHA-1 being better and AES better again. Heading up there is SHA-224....512 etc but at least for the forseeable future they're beyond anything needed for us proles.

So how to explain this? Simple...weak passwords. These "search" applications use pre-compiled hash tables to find the original value. Basically, it's a big-ass dictionary of words along with their SHA1 and/or MD5 hash values. If the hash value you enter is in the table, then it just looks up the word that created that hash. This is why you should create strong passwords to protect sensitive accounts...like this one:

Em=ZaEaGr|oOatLI

Rainbow tables and such like you mean? Yes, in the right hands and with peoples typical password strategies these can 'decrypt' a hash in a few minutes, even a few seconds!

The 'problem' with strong passwords is not that most people don't see the value in their use but that they don't use them for a very simple reason - if they do they can't remember them so write them down - making them less secure than a weaker one they can remember. For that reason if no other a strong password being more secure (in every day terms) is more illusion than fact.

The problem being a password is insecure by definition because it can be so easily passed on by word or as it so often is, by post it.

For those with any interest (and really, it's not interesting at all) there's a simple description of the process here. It does have some factual errors about collisions not having been found, and relative risk but it's easy to follow.

An Illustrated Guide to Cryptographic Hashes

I prefer a combination approach to security but for an online forum that would be way OTT if not impossible. :smile:

 

[B_Hickboy]

Give me a database user ID and password, and I can read anything in the database, PMs included. I've done it with other forums.

To my knowledge, Rob E is the only one who has the password.

The answer is yes. Nobody, even RobE, can go through the stock version of vBulletin to read PMs. But anyone with 2 hours of training and a copy of Microsoft Access is a login name, a password, and one SQL statement away from being able to read everything in any table in any database, PMs included. It's also possible, through PHP or ASP, to create a web page that will display other users' PMs. One need not have the user's password. His login name will suffice, becuase it's stored in a table with the user's system ID, which is usually a number. Private messages themselves are stored as text and can be easily retrieved.

Moral of the story: If you want to make sure that nobody will ever read what you've said, don't say it. Even if you whisper it in the intended recipient's ear, he or she can still repeat it.

 

[B_Hickboy]

Amendment to my above post: It is also possible to hack a database password. It requires a degree of sophistication which few people possess, but it can be done. But if I understand the questioner's intentions, the answer is still the same -- nobody among the moderators and co-admins can read PMs through vBulletin.

 

[B_big dirigible]

So how to explain this? Simple...weak passwords. These "search" applications use pre-compiled hash tables to find the original value. Basically, it's a big-ass dictionary of words along with their SHA1 and/or MD5 hash values.

That is correct, that site is a dictionary; hence its name, SHA1search (a misnomer, as it also performs md5 lookups), rather than SHA1dehash.

 

[DaveyR]

Can you see who is PM'ing whom?

In answer to your question I know that admin can definately see who is PM'ing who. As for Mods that would depend on what powers have been granted to them by admin.

 

[agnslz]

A question I have is whether deleted PMs are truly deleted. I remember the mods saying that threads can never be deleted, merely made invisible to everyone but them. Does the same apply to PMs? When we press the "delete this message" button, does it delete the message entirely from the site's database, or is it still there, just no longer in our account and viewable by us?

 

[B_big dirigible]

I remember the mods saying that threads can never be deleted, merely made invisible to everyone but them.

So the little buggers have been making them private? Figures. I've been noticing more threads "disappearing" lately.

 

[DaveyR]

Mods cannot delete threads or posts but they can unapprove them which makes them invisible. Usually Admin delete them after that if they are not going to be restored. Mods do however have different powers and levels of authorities on different sites depending on what admin allow them to do.

 

[dong20]

So the little buggers have been making them private? Figures. I've been noticing more threads "disappearing" lately.

I've not noticed. I'm not doubting you - I would likely only notice a thread had disappeared if I had posted in it so I'm curious what sort of stuff is disappearing.

N.B. I rarely even read let alone post outside Et Cetera so if they were not there it's unlikely I'd remember them.

 

[mindseye]

A question I have is whether deleted PMs are truly deleted. I remember the mods saying that threads can never be deleted, merely made invisible to everyone but them. Does the same apply to PMs? When we press the "delete this message" button, does it delete the message entirely from the site's database, or is it still there, just no longer in our account and viewable by us?

In the stock version of vBulletin, when a user "deletes" a PM, the space in the database is marked as unused. So the message isn't physically wiped instantly, but is subject to be overwritten at any time when someone else sends a PM. I don't know whether Rob has altered that part of the vBulletin code.

 

[agnslz]

In the stock version of vBulletin, when a user "deletes" a PM, the space in the database is marked as unused. So the message isn't physically wiped instantly, but is subject to be overwritten at any time when someone else sends a PM. I don't know whether Rob has altered that part of the vBulletin code.

Ah, thanks for your insight Mindseye.:smile:

 

[B_big dirigible]

so I'm curious what sort of stuff is disappearing.

I am too. I've only noticed the disappearance of a couple of threads that I know I've posted in, as well as the disappearance - not even banning, but outright eradication - of the members starting those particular threads. And that's not enough to establish a trend.

But there's no doubt that this secret censorship is happening, and it should be no surprise that I don't approve of this sort of gross moderator abuse. That's assuming that one or more moderators are the culprits. The perpetrators may be at higher level than that; I don't see any way for us peons to tell.

 

[dong20]

I am too. I've only noticed the disappearance of a couple of threads that I know I've posted in, as well as the disappearance - not even banning, but outright eradication - of the members starting those particular threads. And that's not enough to establish a trend.

But there's no doubt that this secret censorship is happening, and it should be no surprise that I don't approve of this sort of gross moderator abuse. That's assuming that one or more moderators are the culprits. The perpetrators may be at higher level than that; I don't see any way for us peons to tell.

I suppose one could bookmark each thread posted in then check them in an automated way each month, see which ones turn up missing (no thread specified page) and then ask why. I must admit it seems like a lot of effort (or not), depending of course on how many threads one posts in. But it may unearth any pattern if there's a pattern to be found.

If I relied on memory I doubt I would remember back past a couple of weeks unless the thread was especially memorable. As you can imagine, that's uncommon.

 

[B_big dirigible]

see which ones turn up missing (no thread specified page) and then ask why.

Futile. We the peons have been told on more than a few occasions - in tones both condescending and arrogant - that these questions will not be answered. And certainly none of my questions along these lines have ever been answered. A matter of "policy", I suppose. I still call it abuse.

 

[SteveHd]

It's annoying when a thread I know existed gets "deleted". It happened to me about a week ago. I started a thread to find out if anyone knew about it. Turns out the O.P. was underage and the moderators "deleted" the entire thread. The thread I started is: http://www.lpsg.org/the-help-desk/54614-user-ultimacock-missing-messages.html ... the explanation is in post 5.

 

[dong20]

Futile. We the peons have been told on more than a few occasions that these questions will not be answered. And certainly none of my questions along these lines have ever been answered. A matter of "policy", I suppose. I still call it abuse.

Probably, yes. A least when presented on a one by one basis.

A long specific list of deleted threads and vanished members would be a tad harder to side step (or so I would imagine), while retaining any plausibility.

Perhaps a thread could be started, called "The disappeared". Folk could post details of threads that had vanished and ask why. If nothing else it could be an interesting exercise to see how long such a thread would take before getting locked, 'vanished' and/or the perps banned.:smile:

PS just noticed SteveHD's post above. That could have been a starter for ten.

 

[B_big dirigible]

It's annoying when a thread I know existed gets "deleted". It happened to me about a week ago. I started a thread to find out if anyone knew about it. Turns out the O.P. was underage and the moderators "deleted" the entire thread. The thread I started is: http://www.lpsg.org/the-help-desk/54614-user-ultimacock-missing-messages.html ... the explanation is in post 5.

Congratulations, you managed to get an almost-answer to a direct question. They've never done me the courtesy. The official explanation with which they fobbed you off is still bollocks. Offending user, delete the user. Very simple. The reason for deleting the thread has yet to be explained.