Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security concern Username/Password stored in configuration file settings.py #18

Open
smesdaghi opened this issue May 16, 2013 · 6 comments

Comments

@smesdaghi
Copy link
Member

This is STIG violation and as we know not good practice especially since it is in clear text. we can use the same approach that geoserver does and write the username password in a separate file and encrypt it. here is a segment from STIGs:


The system must use a FIPS 140-2 validated cryptographic module (operating in FIPS mode) for generating password hashes.
• We are currently using MD5 for the database because that is the best available out of the box w/ PGIS. Our statement is we will move to develop a FIPS compliant when required.

Ensure the application transmits account passwords in an approved encrypted format.

1.  If these encryption settings have not been turned on, this is a CAT II finding. 
⁃ If the data encryption functionality is not configurable and the identification and authentication information is stored in ASCII or another readable format, examine the actual data to determine if they are in clear text. 
2.  If the authentication data is readable, this is a CAT I finding.

The designer will ensure the application stores account passwords in an approved encrypted format.

The designer will ensure the application transmits account passwords in an approved encrypted format.

(APP3350: CAT I) The Designer will ensure the application does not contain embedded authentication data.

(APP3360: CAT II) The Designer will ensure the application protects access to authentication data by restricting access to authorized users and services.

All account passwords, both administrative and non-administrative, must comply with the following:
• Passwords must be at least 15 characters long.
• Passwords must contain a mix of upper case letters, lower case letters, numbers, and special characters.
• When a password is changed, users must not be able to use personal information such as names, telephone numbers, account names, or dictionary words.
• Passwords must expire after 60 days.
• Users must not be able to reuse any of their previous 10 passwords.
• Users must not be able to change passwords more than once a day, except in the case of an administrator or a privileged user. Privileged users may be required to reset a user’s forgotten passwords and the ability to change passwords more than once per day.
• When a password is changed, the new password must differ from the previous password by at least four characters.

@jj0hns0n
Copy link

Thanks for clarification syrus! Just to make sure this is ok to post
publicly? Remove this comment if so.

On Thu, May 16, 2013 at 9:45 AM, Syrus [email protected] wrote:

This is STIG violation and as we know not good practice especially since
it is in clear text. we can use the same approach that geoserver does and
write the username password in a separate file and encrypt it. here is a
segment from STIGs:

The system must use a FIPS 140-2 validated cryptographic module (operating
in FIPS mode) for generating password hashes.
• We are currently using MD5 for the database because that is the best
available out of the box w/ PGIS. Our statement is we will move to develop
a FIPS compliant when required.

Ensure the application transmits account passwords in an approved
encrypted format.

  1. If these encryption settings have not been turned on, this is a CAT II finding.
    ⁃ If the data encryption functionality is not configurable and the identification and authentication information is stored in ASCII or another readable format, examine the actual data to determine if they are in clear text.
  2. If the authentication data is readable, this is a CAT I finding.

The designer will ensure the application stores account passwords in an
approved encrypted format.

The designer will ensure the application transmits account passwords in an
approved encrypted format.

(APP3350: CAT I) The Designer will ensure the application does not contain
embedded authentication data.

(APP3360: CAT II) The Designer will ensure the application protects access
to authentication data by restricting access to authorized users and
services.

All account passwords, both administrative and non-administrative, must
comply with the following:
• Passwords must be at least 15 characters long.
• Passwords must contain a mix of upper case letters, lower case letters,
numbers, and special characters.
• When a password is changed, users must not be able to use personal
information such as names, telephone numbers, account names, or dictionary
words.
• Passwords must expire after 60 days.
• Users must not be able to reuse any of their previous 10 passwords.
• Users must not be able to change passwords more than once a day, except
in the case of an administrator or a privileged user. Privileged users may
be required to reset a user’s forgotten passwords and the ability to change
passwords more than once per day.
• When a password is changed, the new password must differ from the
previous password by at least four characters.


Reply to this email directly or view it on GitHubhttps://github.com//issues/18
.

@jj0hns0n
Copy link

@smesdaghi is this a high priority thing for this TD?

@ghost ghost assigned jj0hns0n Jun 18, 2013
@jj0hns0n
Copy link

@mooreja @smesdaghi what is the status of this for the TECD? Is it something we must do now/immediately?

@smesdaghi
Copy link
Member Author

@jj0hns0n I'd say it is important but not a blocker for TD2. @ScottEvil please correct me if needed. thanks!

@ScottEvil
Copy link
Member

@jj0hns0n @smesdaghi I concur. Would be good to have resolved by OD1 I think.

@ScottEvil
Copy link
Member

@jj0hns0n @smesdaghi Moved to the OD1 milestone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants