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

Subetha users password encryption patch #43

Open
GoogleCodeExporter opened this issue Mar 30, 2015 · 5 comments
Open

Subetha users password encryption patch #43

GoogleCodeExporter opened this issue Mar 30, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

PFA the patch that uses one-way password hash for subethamail users.
The encryption at the moment is SHA 256 which provide us modest
security which is better than plain passwords.

My primary goal was to get rid of plain passwords while not modifying
too many of subethamail files and existing functionality/schema.

To make the patch work on existing PostgreSQL database, steps similar
to following need to be taken (via psql or your favourite tool):

1. Enable pgcrypto contrib module by executing
share/postgresql/contrib/pgcrypto.sql (tested on vanilla PostgreSQL
9.0 - it is required to get sha256 hash within PG)
2. UPDATE subetha.person SET passwd=encode(digest(passwd,'sha256'),'hex');

Original issue reported on code.google.com by usman.sa...@gmail.com on 15 Nov 2010 at 10:31

Attachments:

@GoogleCodeExporter
Copy link
Author

Cleaning up some if( to if ( and attaching the patch.

Original comment by usman.sa...@gmail.com on 15 Nov 2010 at 10:47

  • Added labels: ****
  • Removed labels: ****

Attachments:

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

After some detailed testing, few minor issues were encountered. Following 
revised patch address following issues:

- Delete list use-case password encryption
- Removing passwords from create list and subscribed list email templates.
- Introducing custom byte[] to hex conversion method instead of BigInteger 
because later doesn't cater for padding leading zeroes which may conflict with 
database specific conversion (for instance, pg function encode pad leading 0s). 

Original comment by usman.sa...@gmail.com on 20 Nov 2010 at 5:34

  • Added labels: ****
  • Removed labels: ****

Attachments:

@GoogleCodeExporter
Copy link
Author

OpenSCG is using this in production.  Thanks Uzi.

Original comment by lussm...@gmail.com on 30 Dec 2010 at 4:24

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Is there a patch for mysql by any chance?

Original comment by runitsaa...@gmail.com on 12 Aug 2011 at 4:58

  • Added labels: ****
  • Removed labels: ****

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

1 participant