Closed (fixed)
Project:
Security Review
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Jun 2010 at 00:28 UTC
Updated:
6 Feb 2023 at 10:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
gregglesIdeally you could combine this with the list of "trusted roles" to find users with bad passwords and advanced permissions.
Comment #2
gregglesHere's a query to do that:
It gives you results like:
So, if it's a count of zero you know that the user doesn't have one of the advanced roles.
Comment #3
coltraneAttached patch implements greggles' check for users with certain roles whose passwords are their username. It needs work because it needs more code comments, documentation, and expanded integration with forthcoming rainbow table check.
Comment #4
gregglesThis all looks awesome to me.
One other thought I had is that theoretically it's possible for UID to not have any roles, still have full permissions of course, and have a weak password. I think uid 1 should be special cased in the processing here.
I also fixed a variable typo and a typo in the message for IP's with lots of failed logins.
Comment #5
jleinenbach commentedAs an idea, bad passwords could be tested by checking against a cracked hashes list, downloadable e. g. here:
http://opencrack.hashkiller.com/
Comment #6
greggles@jleinbach, I generally like that idea, but we want to keep the security_review module download relatively small. My current thinking is to use a really small list of popular passwords and provide a way for sites to use an alternate set of passwords for a more complete check.
This particular issue has kind of become about checking username against username-as-password. I think we should change the UI so it is really about just that and create a new issue about how to do checking of commonly used passwords: #897960: test password strength against an extensible list of passwords that defaults to really common ones.
Comment #7
coltraneSmall reroll, I only added some comments.
Comment #8
coltraneUpdate for new check help and modified UI to only talk about usernames as passwords.
Comment #9
coltraneCommitted http://drupalcode.org/project/security_review.git/commit/0b90323 for 6.x-1.x
Port to Drupal 7 will require hashing in PHP but it's still a valuable check.
Comment #10
dsnopekAttached is a patch that ports this check to Drupal 7! A bunch of the D6 code was present in the D7 branch, so rather than adding it new, it modifies what's there.
Comment #12
dsnopekCommitted patch to 7.x-1.x! Needs to be ported to Drupal 8.
Comment #13
tlyngej commentedI have ported this patch to version 8.1.
Basically just added a new Check extending class (
Drupal\security_review\Checks\NamePasswords) and amended thesecurity_review_security_review_checks()function insecurity_review.module.Comment #15
tlyngej commentedAnd, hey, why not submit a patch with content!
Comment #16
tlyngej commentedComment #17
tlyngej commentedNew patch, where the displayed list of users are properly escaped.
Comment #18
tlyngej commentedComment #19
vuilRe-roll is needed.
Comment #20
visabhishek commentedJust re-rolled the patch security_review-name_password_check-830970-17-8.patch
Comment #21
smustgrave commentedAs much as I like this idea is that out of the realm for this module? Shouldn't that fall under https://www.drupal.org/project/password_policy
Will let one of the maintainers to decide but not sure if it should be added.
Comment #22
gregglescoltrane, dsnopek and I are all maintainers who did work on this to bring it to the module.
I think password_policy should keep a site safe for new password changes, but this module gives a sense of whether a site has a problem regardless of when the problem was introduced.
If password_policy has a feature like this I would definitely be willing to not add this to Drupal 8.
I also don't see it as a top priority. If you aren't motivated by the idea you don't have to work on it :)
Comment #23
smustgrave commentedSince the work has already been done don't see any harm. Just needs to be updated.
getUsername() has been deprecated and removed.
Comment #24
asad_ahmed commentedMade changes as per #23, replaced deprecated getUsername() with getDisplayname(). Thanks
Comment #25
smustgrave commentedPatch #24 removes code from #20 for the module file.
Also when viewing the details this error is thrown Warning: foreach() argument must be of type array|object, string given in template_preprocess_item_list() (line 1147 of core/includes/theme.inc).
Comment #26
smustgrave commentedReverted back to #20. Fixed the getUsername issue and error reported in #25
Comment #27
smustgrave commentedComment #28
smustgrave commentedReroll.
Comment #30
smustgrave commentedComment #31
smustgrave commentedComment #32
smustgrave commentedComment #34
ednark commentedI have tested this and it functions as expected without errors.
Tested on 10.1.x-dev with a standard install
module drupal/security_review:2.0.x-dev@dev
branch 830970-test-password-strength
patch applied https://www.drupal.org/files/issues/2023-01-13/830970-30.patch
Test procedure:
Create new User
Set Username to TEST and password to TEST
rerun security_review tests
see failure for "Username same as password"
goto details and see the TEST user listed as the problem
Comment #37
smustgrave commentedComment #38
vuil