I've just done an install of WI 1.1.2 and noticed two issues with setting up the first account.
1. The username for the first admin account is hard-wired to be 'admin'.
It took years before the WordPress authors were persuaded that doing this was a bad idea, because it means that anyone wanting unauthorised access knows half of the username/password combination for an admin account. (It was several more years before they were persuaded that suggesting using 'Admin' was a bad idea too, but at least not insisting on it was a step forward.)
Is there any reason why line 128 of admin/setup/install.html.php
<?php $form->renderText( $this->tr( 'Login:' ), 'adminLogin', array( 'value' => 'admin', 'size' => 40, 'disabled' => true ) ) ?>
cannot be changed to something like
<?php $form->renderText( $this->tr( 'Login:' ), 'adminLogin', array( 'size' => 40 ) ) ?>
to allow users to pick their own admin account username?
2. There doesn't seem to be any protection against automated attempts to bruteforce passwords.
So knowing the username to get an admin login, a hacker is allowed endless attempts to get its password.
The event log shows unauthorized access to various pages, but this is stored in the database. Can there be a log file for things like failed logins? This would enable a monitor like fail2ban to notice them and, after a few failures from the same IP address, block them.
At the moment, I am using .htaccess to set a password to get to index.php, but...
After installing WebIssues, you can create a new user with any login you like [and administrator access], then log in as that user and disable the built-in 'admin' account.
Note that the password hash is calculated with 2^14 iterations, which makes bruteforcing a reasonably strong password more difficult. You can increase the password stretching strength in system/core/passwordhash.inc.php if you like.
It wouldn't be difficult to create a log file for failed logins. Look for the loginCommon() method in system/api/sessionmanager.inc.php.
Regards,
Michał