I just ran te following SQL on one site.



Over 50% of the members have used the same characters for both fields during signup.

I think this is a useful "option" for webmaster/moderator UserIDs, but a waist of time for other users.

Ok This is a community CMS lets see it's real value and run a Poll

I always have trouble with people being unable to use a XOOPS site. They are just stupid it's not their fault, they are just not tech heads or geeks and fail to see how to do some things.

So my vote is to always make things as easy as possible by removing all fluff.

I also like security, there is always someone with some spare time trying to ruin your day.

I personally dont think display name gives you any more security over the hassle it will give my site members, so i would vote against it. But i do remmeber GI JOE (sorry if i have the wrong guy) making a point a while back by making a post with someone elses id that caused an uproar....he really did make a point.

At the end of the day the world has changed and all successful companies are now delivering what people want instead of telling them what they are going to get. Take google, the public dictated what they wanted (easy searching) and bam they became the biggest SE around. They others all told you how you were going to get the results and they were #OOPS#.

So we need to deliver what the users want, not what we think they need.

my 2c

cheers
Gecko Bring on the POll

Quote:

Just a quick note. This feature being "protested" prevents social hacking, not brute force dictionary attacks. They are very different. In many forums, it's fairly simple to get an idea what some users may have for a password based on what they write about. Someone that likes cats a lot and has one named Fluffy has a decent chance of using Fluffy, fluffy1, myfluffy, or something similiar as their password. Spouse names, children, pets, hobbies -- baaaaaaad passwords.

Social hacking is much more of a problem than brute force hacking. If the hacker has access to the database, it's game over anyways.

I'd like this feature to remain part of Xoops, please. What I don't like is that this new feature does nothing to protect older users.... Great for new installs but of somewhat less limited use for established sites.

I'd like to see a notification go to the admin when someone misses their password 'x' many times.

I'd like the option to prevent users from changing their name. This should be the default.

I'd like the option to turn it off. XOOPS should make both usernames the same automatically in this case. That way you can change your mind later.

I'd REALLY, really, really like a block that shows all questionable information like failed login attempts, simultaneous logins, maybe even logins outside of the user's normal login times. Add in the standard SQL injection detection and other niceties from the Protector module. It should include IP and the option to ban. Distribute it with the core. XOOPS needs some form of intrusion detection reporting and logging. This sounds like a good place to start.

Some very sensible suggestions there Speed - i'd agree with most of that as well.

whttp://www.xoops.org has about 9000 log entries in the protector module. That's a hell of a lot of go through to see what is going on on this site.

I don't want to have to go through the list of missed attempts, I just want to be sure that after 3 failed attempts within x time, the account is suspended for y time.

That's enough for me. I don't want to slow down the site with the collection of huge amounts of data that is harmless 'background noise' for the most part anyway.

The authentication module for XOOPS 2.4 will be advanced tho, but it'll be the first opportunity some of these requests will be granted.

Herko

Quote:

actually, your logic in calculating is flawed..

by not knowing the username, when bruteforcing, each username combination would have to be tried with the exact same password configuration. they are not combined!!! you would have to try username x with password ??? untill all possible passwords have been tried, then you would need to do username y with those exact same password combinations, then username z and so on and so on. how many years do you have?

quite simply, you can brute force the username, but even if you get the username right, and the password wrong, you would not know.. so to bruteforce 2 compulsary fields quite simply would take an exponentially large amount of time. each brute attack would have to be performed over and over again with each password/username combination and the longer the username and the password significantly increases the amount of passes the brute force would need to do.. in actual fact it would not be worth a brute forcer bothering with. and a proper cracker would tell you the same thing it would effectively force them to find other methods.. quite simply a brute force attack would not be feasible.

making it optional that webmasters/admins can only change the display name is a quick 5 mins work.. a simple if ($is_admin) statement in the code.. and if you want it optional to allow members to change it, then add the option to the configs in xoops_version.php.. it isn't difficult to do, but would require more time to add the is_admin check to each place where the displayname can be edited..

Quote:
Very good point and I agree with you for the most part. Automating suspensions is a good thing. But you really don't need to see 9000 log entries unless you want to; you just need to see a filtered subset of those log entries. And unless you suspect a problem or you're doing a periodic security audit, you probably don't need to view any log entries.

Add this to my list of feature requests: when displaying security information, XOOPS admins need to be able to define the time period shown. Since last view, last day, last week, last month, last six months, last year and view full log sound like they'd cover most admin's needs.

Xoops is used on some very large sites and trying to monitor security at the level I am asking on a daily basis would be prohibitively time consuming. However, XOOPS sites are attacked at times. Being able to easily access this information could be invaluable; much like turning on PHP debugging is useful for tracking down coding errors. Sometimes, you just need to spend the time sifting through the information to fix the problem -- but we need access to the information in order to do so.

I am not a coder so I'm likely just being naive, but I can't imagine a security block could slow things down on a site. The data is already being collected and logged (I hope!). I am simply requesting a means to actually display it from within XOOPS in a user-friendly format. Additionally, it would likely only be displayed to an extremely small subset of the site -- likely just the admins.

Thank you for considering my suggestions.

Quote:



Hi Monty,

I’m quite certain my logic is actually flawless. I just don’t think you quite understand what I’m trying to get across. Which is understandable, sometimes the simplest things are the most difficult to “get” and also to explain.

Actually, apart from you misunderstanding the essence of the point I’m trying to make, I fully agree with most of what you said. If I had actually SAID any of what you claim I have said, you would have made some good points. You are right, this IS an issue of exponential values, which is why I used (Username+Password)^X to illustrate that you could get the same exponential level of security from a SINGLE password. However, you are wrong in saying I believe a hacker would ACTUALLY try to hack an account by entering sequential log-in values to find a password in an exponentially large number of password possibilities. That method could literally (depending on how long your Loginname and Password were) take a hacker the rest of his life to find the correct combination. He’d probably still be looking for it in his grave. I just thought that went without saying. Sometimes of course it is "partly sequential"...but never TOTALLY. I don’t remember saying once that hackers used totally sequential methods, I think I’ve said something along the lines of: “most hackers use trial-and-error and guesswork”. Trial-and-error does not have to be sequential and guessing random passwords is not. Brute-force hackers usually also combine their hack-scripts with dictionary databases to, btw. So, the smart ones, would never start a sequence like: AA, AB, AC… Good scripts would work in a similar way as many domain-name registration sites work, when they offer you alternative AVAILABLE variations on a domain-name you wanted which is not available. Some of the even more complex ones do all sorts of other crazy-complex stuff too, I’ve heard. :)

You are also wrong in saying: “they are not combined!!!”. The Loginname and Password combine and together make-up the SINGLE “password solution”. The “problem” is just to find the TWO-field (Loginname & Password) combination which unlocks the account, instead of one-field solution. This is in effect no different from the OLD one-password system “problem” which was to find the individual LETTER combinations that unlocked an account. In effect the Loginname and Password = *THE* Password. There is only ONE password, even if you choose to split its entry into two fields. There can only EVER be one password. Hack-scripts will just need slight alterations to handle input.

For instance…

Loginname: AB
Password: 12

…here *THE* Password is AB12, in that order. To make the separation clearer you can use brackets: (AB)(12). So the first-half of *THE* Password is (AB) and the second-half is (12). In the old-style login, *THE* Password would be the combination of Username and Password: (Username)(Password), in that order.

If we were insane, we could make our users log-in with *four* entry fields. If we done that the login would be…

Loginname1: A
Password1: B
Loginname2: 1
Password2: 2

…*THE* Password would _still_ only be: (A)(B)(1)(2) = AB12. All that is different is that we have divided the input of *THE* Password into four-quarters, instead of two-halves.

You said you could not brute-force hack a two password system because the exponential possibilities make it nearly impossible. Well, as I’ve said, blind brute-force hacking is NOT the point I’m making. Very few hackers use total blind brute force, we all know that. BUT, if they did, brute-force hacking a two password system is no more difficult than a single password.

The exponential possibilities of the two-letter Loginname and Password above both combine to make an exponential value of: (36^2)*(36^2). The “power of 2” comes from the fact that there are two letters in this case and 36 is because there are 26 alphabetic characters + 10 numeric characters you COULD choose in your password. So…

Loginname = 36^2 possible values = 1,296
Password = 36^2 possible values = 1,296

Also, you were right in saying that even *IF* you knew Loginname, you would still have to find the Password out of 1,296 different possibilities. However, like you also said, you are NOT likely to even know the FIRST half (Loginname) of *THE* Password (Loginname+Password) and not knowing Loginname FURTHER increases the odds against you by a factor of 1,296. So in this case with our two letter Loginname and two letter password, the total exponential odds are 1,296 * 1,296 = 1,679,616 against a haxx0r “guessing” the combination. That’s a hell of a lot of guessing this guy’s going to have to do and we’ve helped by only making it 4 letters long and TELLING him that it’s only 4 letters long.

Now my simple - crystal clear - point is this:

*THE* Password: “AB12” is NOT more difficult to hack just because you have hidden AB in the Loginname field and it can’t be seen. Why? Because the TOTAL exponential odds against guessing…

Loginname: AB
Password 12

…are *EXACTLY* the same as the odds against you guessing…

Username: MyUserName <= is SEEN by all, so no “guessing” or haxxing
Password: AB12

The Password in the above Old-style Username login has the exponential value: 36^4 = 1,679,616, which is the same as the *TOTAL* exponential odds against you finding both Loginname = AB and Password = 12.

Any Loginname and Password you can think of can be equaled, as far as “security” is concerned, by the Old style login system. For example, suppose you think the following example of a new-style XOOPS login account is safer than an Old-style login account:

Displayname: Tommy
Loginname: Foobs
Password: pw123ohh

…you would be wrong. Because you could simply *COMBINE* “Foobs” and “pw123ohh” into a single old-style Password and have EXACTLY the same exponential odds against guessing or hacking it! (see above for the example of what I’m talking about) So the following Old style account is no LESS safe…

Username: Tommy
Password: Foobspw123ohh

The Password has EXACTLY the same odds against a hacker finding it. This really MUST be clear to any still reading this now. Or else there is NO hope for humanity!!

Speed also mentioned above “social hacking” and that the new Loginname’s help because hackers try passwords relating to information they KNOW about you. Again, this is a security illusion. For example, if you like the band Radiohead, you might be totally stupid enough to have an old-style login such as:

Username: Tommy
Password: radiohead10

I agree, that would be EASY for a social hacker to hack. However, the very same type of person dumb enough to create an account like that is also likely to create something like this with the new system:

Displayname: Tommy
Loginname: radio
Password: head10

With this new system, all you have really done is prevented a hacker from typing in a Username to IDENTIFY the account he is about to hack. Now hackers are not dumb. Tommy’s hacker will not suddenly think: “Oh, eeeer, uuuum…wait a minute! There’s no field for me to type Tommy’s Username! They’ve beated me!!”. Far from it, he will simply begin hacking the Loginname and Password fields using the same social hacking logic and scripts as he would with an old-style Password field, KNOWING in his own mind that it is Tommy’s account he wants. The same probabilities of finding it are involved, it’s absolutely no less probable that he will find the new-style login account.

Now there is also SECURITY RISK in this "new-style" login system that people have failed to notice. While Tommy’s hacker is “randomly” or even “skillfully” entering what he THINKS might be Tommy’s Loginname and Password, he is also very likely to accidentally stumble across SOMEONE ELSES account!! In fact that is HIGHLY likely and depending on how many users you have, the odds against “accidentally” discovering someone else’s can dramatically decrease.

If this hacker was hacking Tommy’s account using Tommy’s username, he would never change the Username field with each attempt and so he would only ever have a chance of hacking open Tommy’s account. With this new system he might come across many other people’s accounts before he finally finds Tommy’s. Now THAT'S a _real_ security risk for you to think about!

As I have said before in a post, Unix*, the world’s most secure system - whether it’s being use online, or offline - has a default SuperUser admin account called Root. Everyone and his Grandmother knows that the administrative account exists with the Username Root. It’s an active account on Unix* based University networks, Business Databases and personal computers all over the world. The reason most Unix* based OS’s have not removed this well-know account is because they know that it really DOES NOT MATTER if the whole world knows about Root. As long as the password chosen for Root is long and difficult to guess.

Changing the name of the Root account on Unix* systems would simply mean that the name of the User account would be ADDED to the “Password problem” by a hacker. The same “increase in security” gained by changing the Username "Root" can be achieved by leaving the Root Username as it is and adding what you would have called the new account to the password. That increases the security by THE SAME EXPONENTIAL AMOUNT!

Speed: there is actually a reply to you...somewhere in the rant I just posted above!

That's a lot of math! But, I'm going to correct a few errors in assumptions -

A standard 101-keyboard has more than 36 choices for characters. And, the standard XOOPS system allows using case-sensitive passwords with alphanumeric and symbolic characters. Not all symbols are allowed, but enough are to make things interesting.

Users are funny - they don't care much about security, at least here in the US. Why do you think your Social Security number gets used for identification (it's not supposed to be, according to the Social Security Administration)? Why do banks ask for your mother's maiden name? People can't remember lots of different abstract bits of information. They need to have it relate to something. So, people pick easy to remember (and guess) passwords.

I agree that splitting the authentication into multiple fields does not increase the complexity of the 'password' (there is still only one combination that will unlock the code), but it does make it longer. I disagree that not knowing part of the 'password' doesn't make it harder. It is true the number of possibilities doesn't change, but the number of guesses does. If not knowing part doesn't matter, why do password fields use masking? As an example, this post contains my user name. Without any other information, what domain is my email address in? It could be any of over 63,364,626 domains registered worldwide. domain registrations.

The *nix argument about the root user is somewhat interesting, but not quite the same as what is being discussed here. *nix administrators know about the root user and how to prevent an attack on that user. It's there, but they do something to protect that account, and limit all other accounts from elevating themselves to greater priveleges. Those of us that have experienced attacks on our sites make #OOPS# sure we change the MySql root user password, the anonymous user access to the db, the anonymous ftp users, and protect our web directories with htaccess files, Windows user groups, etc. We're talking about general users and the vulnerability we have as site administrators when we don't put some restraints on accessing and posting content to our sites.

While there may be 'social' hackers just guessing at username/password combinations, there are a great deal more of crackers out there that are using brute force attacks and dictionary attacks on passwords, along with packet sniffers and keyloggers.

Basically, increasing security does increase inconvience, and any web or system administrator needs to be able to determine which end of the spectrum they are comfortable with, and which provides them with the best balance for the user experience and the information you are responsible for.