Yay for PMs being hacked, I have a lot of stuff in there. Although most of the stuff is kinda useless...so okay.
|1.||Something which by its existence and use leaves people believing they are more secure than they actually are. It is one thing to be insecure, it is something else to be insecure whilst believing you are secure. This is mostly the latter.|
For me (and perhaps others) this would be a chance to be compliant with the (local) law.
Even if you don't do it, nevertheless there's a way to do you evil and to bring you in trouble.
Just a thought:
How can you prove that you don't do it if someone else accused you to do it? ;)
My bank uses some kind of extra check where if you log in from an "unknown" computer, it asks you verification questions. So even if your password is stolen it can't be used on another computer without knowing the answers to very specific personal security questions. It's too bad that technology isn't available to all, but it probably adds a lot of complexity.
@xrunner My bank used to require from us to download a certificate file and to install it in the browser. If you are using browser without certificate you can't login. But this method was deprecated, now they require digital sign. SMF's Login Security mod offers some additional protection - user defined IP range of which he/she can login.
Much as I hate to get involved, someone who I owed a favour to asked me to comment.
Firstly, you're incorrect about some of your assertions. The salt you're referring to is not used to compute the password hash. The password in the database is stored as SHA1(strtolower(username) . password) and has been for a very long time in SMF. No extra table is required for this. Oh, and if you notice, it's not actually 'rolling their own'. It's following standard practice (take the password, add something that's account specific and hash that)... and in ANY case the salt would be useless if it were used because it's RIGHT THERE IN THE TABLE. It's only any use if it's otherwise an unknown, but since it's not an unknown element, because it's right there in the table, it doesn't really help any since you already have to construct a rainbow table for every account in the first place.
Secondly, not all hosts are currently using 5.3.7 and up. There are still some very major hosts running 5.2 and in fact some hosts still offering 4.4 hosting for the time being, even though 5.3 itself is officially maintenance only now, and most of SMF's typical demographic applies to those because they're the budget end of the market. So that's not really something SMF can implement in a realistic fashion, but I guess reality of lots of support requests (and there are already multiple requests per day related to one really poor free host and their limitations, but hey, let's add a crap ton more!) is irrelevant.
Thirdly, I don't believe you understand what it means by 'decrypting the password'. It is mathematically impossible to actually decrypt the password hashed by a digest hash like SHA1. What you do is find something that when combined with the username and then hashed will give you the same hash as what you're looking for... that means potentially multiple passwords will actually work because you're not looking to find the original, you're merely looking for a collision. You may want to search for multiple collisions for this very reason.
Fourthly, it is well researched and documented that most people suck at choosing passwords. A 2011 study (whose link I can't immediately find) found that 'password' was still by far the most common password, followed by '123456' and direct variations of that. Breaking into systems can be done with that fairly easily.
Incidentally, pushing everything to bcrypt may not be the smartest idea in the world. If everything is pushed to bcrypt and a *single* vulnerability is found, suddenly a lot more targets are actually located. Having everything in a slightly different form does at least have some benefits with respect to lowering the immediate attack vector options. There is a little comfort - but very certainly not a lot - from security through obscurity, but it is no substitute by any means for real security.
Thing to note: the system is only ever as strong as the people who hold the keys to it. It is often significantly easier to leverage a weakness in a person rather than in the technology under them, as was done here, to leverage the access to perform queries on the database. Once the database is compromised, best security practice is to assume it is *always completely compromised* even if the data is encrypted with the strongest possible methods, because you never know what resources the intruder has to break that.
Consider: this attack was to force an admin's account. If there was no way to run arbitrary code through some fashion with an admin's account or to pull a database backup of some kind, there would be less risk. In fact, if there is no method by which to run arbitrary code or pull a database backup without server access directly, you need to do more than brute force that account, and proceed to brute force a server account. If someone's already gotten into the server itself, assume everything is compromised anyway because by definition it is.
The whole thing about hashes is only an issue if someone gets into the server or otherwise can obtain raw access to the tables and right now there are ways by which an admin can do just that, either by splicing code into template files, or by uploading a package. Stronger controls need to be added to these to prevent arbitrary code being able to be run with just an admin's account, for example enforcing upload via FTP of plugins (as other software does), as well as limiting the ability to run arbitrary code from the admin panel by removing the ability to edit files from said admin panel and enforcing use of either hosting control panel or FTP download/local editing.
I see where you're going but honestly you're picking on one of the stronger links in the chain. There are far, far many more issues to consider... like how on a number of shared hosting setups it is actually possible for your setup to be hijacked as soon as you install a mod. Or how in a number of shared hosting setups it's possible for your entire database to be compromised and with you not being able to do *anything* about it whatsoever. But of course these are minor considerations when compared to worrying about what will happen when a hacker gets in... I'd personally prefer to keep them out in the first place where possible, rather than tightening up what happens when they already have. (Not that you shouldn't ALSO do that, but in terms of priority, it's really a secondary consideration. Don't worry about locking up the family silver if the front door is already unlocked.)
I know more of the story but cannot reveal details without breaking certain confidences.
In any case, haven't you since been banned from sm.org?
SMF 2.0.4 and 1.1.18 security patches have been released. on February 01, 2013, 05:27:00 PM Critical security patches have been released, addressing few vulnerabilities in SMF 2.0.x and SMF 1.1.x. We urge all administrators to upgrade as soon as possible. Just visit the package manager to install the patch. SMF 2.0.3, 1.1.17 and 1.0.23 security patches have been released. on December 16, 2012, 11:41:05 PM Security patches have been released, addressing a vulnerability in SMF 2.0.x, SMF 1.1.x and SMF 1.0.x. We urge all administrators to upgrade as soon as possible. Just visit the package manager to install the patch.
Simple Machines Community Forum
An Error Has Occurred!
Sorry Guest, you are banned from using this forum!
Account suspended by user request
This ban is not set to expire.
Through dangers untold and hardships unnumbered, I have fought my way here to the castle beyond the Goblin City to take back the child that you have stolen, for my will is as strong as yours, and my kingdom as great — You have no power over me.
That is pretty insensitive of you. Dad past away over a year ago.
But the facts and truth is, we have not logged into or posted anything on the SMF forum in over a year.
This is my last post here over a year ago
As an added thought, if you prefer to discuss me or my Dad further, it should probably be done by email. So if you want send me an email and we'll try to clarify any misunderstanding that way rather than detract from the original topic.
Yes, because May 12, 2013 is more than one year ago.This is my last post here over a year ago
2. Kindred has the issue exactly correct with respect to password changing. I still believe that changing them even yearly isn't necessarily ideal, however I can see the logic of this.
3. I also believe it would be wise for both SMF and Wedge (and anyone else, for that matter) to adopt a system whereby a user's password can be expired and prompting a user to change it. Of course this does nothing for users who don't log in any more, perhaps something else needs to be considered for that situation.
The problem is if a user hasn't changed it in a period of time (e.g. a week after it was force-expired), it needs to be changed automatically but there are security issues with that, e.g. if the user's email is outdated, but also emailing a new password out is inherently insecure too. There's not really a truly great way to solve that aspect.
Can it not be automatically and silently changed to some random series of characters (without sending out any notifications)? Should that user attempt to log-on in future, he will have to go through the "lost password" routine.The problem is if a user hasn't changed it in a period of time (e.g. a week after it was force-expired), it needs to be changed automatically but there are security issues with that, e.g. if the user's email is outdated, but also emailing a new password out is inherently insecure too. There's not really a truly great way to solve that aspect.
Yup, passwords that change without notification are usually indeed a sign that something bad has happened. Malware? Maybe. What it does show is that your account has almost certainly been tampered with but not necessarily via malware - there are other ways for your account to be tampered with.
Well obviously someone might have been looking over my shoulder or hacked into my WLAN or there might be some rogue admin but I think it's far more probable some kind of bullshit program.
|1.||Relevant xkcd : http://xkcd.com/936/|
1. Relevant xkcd : http://xkcd.com/936/
1. Relevant xkcd : http://xkcd.com/936/
I trust this password manager. :-)
If you're okay being paranoid why shouldn't I be okay with that? :)
If you're okay being paranoid why shouldn't I be okay with that? :)