Quote:

This is what I read...

If I don't know any of the characters in a 4-character username/password, there are 1,679,616 possibilities for me to brute force guess. (more if you use all acceptable ascii characters)

If, on the other hand, I already know 2 characters (the username), I only have 1,296 combinations to guess.

Or, did I mis-interpret your example?

Good answer.

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.

I tend to agree with David on this - the feature isn't that confusing, and it does provide another level of security. I would only ask that the DISPLAYNAME have the same configuration as the user email field - allow the admin to turn on/off user edits of that field. Also, because of some of my sites need to be monitored for acceptable content (my church's, for example), I would like notification/approval for any changes, if the user can edit.

More information may be needed...

Do you have Protector module installed and activated?
* 2.54 is the latest
Are you using FrontPage extensions?
* disable or remove them if you are not
Have you changed ALL your passwords for your host account?
* this includes cpanel, ftp, FrontPage
Is your anonymous ftp setting buried somewhere you don't notice it?
* find it and disable it

The host (or your log files) should be able to tell you the origin IP of the attacks. Use your htaccess file to redirect them.

(second attempt at posting this - I took too long the first time...)

Basically, I think the real challenge is getting programmers out of the design, which is why XOOPS uses templates, themes, and smarty. And, I think the designers need some guidelines for proper theme development.

Here's some things I have discovered -
1. Elements, Classes and IDs are not always used correctly in XOOPS (Core and Modules). You can often find the same ID tag on more than one element in a page, which is not valid - this should be a class, instead.
2. Module styles have set attributes for html elements that affect the entire site, not just the module's appearance. If you are going to style an element in your module, at least give it a class or ID so you don't break someone else's theme.
3. Inline styles make it necessary to edit the templates to get control of the style - not a good thing.
4. New selectors that need to be added to your theme's stylesheet so the module/block displays correctly are also not a good thing.
5. Having stylesheets all over the site is also not a good thing (how many places do I have to go to change the appearance of my site and the modules I have selected?)
6. Lots of nested elements makes it difficult to track down just what is affecting an element's appearance. Using WebDeveloper in Firefox (Outline Selected Element) sometimes doesn't get to the element before it goes out of the window....
7. Different browsers display styles differently. Trying to create a stylesheet that works in all browsers can be maddening. A method for having multiple stylesheets to handle browser differences would be good. Here's some example code:


With, or without tables, all of these things need to be addressed in a XOOPS module/theme design document.

</my 2 cents>

$_SERVER(REMOTE_ADDR) contains the IP of the accessing computer.

What kind of abuse are you really trying to prevent? As a user, I may not always log in from the same location, or if I have a dial-up account, I may not always be assigned the same IP.

->Protector module logs IP of attempts hacks and abuses.
->CBB can log IP of posters.
->Xoops online module shows IP of currently logged in users
->Uservisit module tracks pages visited by members and time/lenght of visit
->X-monitor is an expanded Uservisit module, tracking actions by users

Good luck.

If you had such a capability, how would you go about differentiating different valid users from the same IP (shared interent access from behind a corporate router, for example)?

The monthly calendar does not highlight the current date, for whatever reason. If you click on a date, then find the 'Today' button in the toolbar, you will be taken to the current date (In any view).

The highlight does move as you scroll the calendar, maybe so you can look ahead on the same day of the week? I've used Outlook for a long time, and haven't found the benefit to not highlighting the current date on the calendar.

blocksadmin module is a great way to manage permissions for groups in one place. Many developers also utilize the myblocksadmin code in their modules.

But, I agree, there can be a lot of granularity in permission management, and inheriting permissions would be a great feature of any module. I've had forums that aren't viewable by a group because I forgot to set the appropriate permissions, but the category had the permissions I wanted - the forum should have inherited those permissions, at least.