topic Re: Storing User Passwords Securely (A.E) planned? in Alfresco Archive

Storing User Passwords Securely (A.E) planned?

udoderk — Wed, 20 Mar 2013 13:22:13 GMT

Hi Activiti Core Team,now i'm found, that the user passwords are stored as plain text. The Storage in this way is not a good solution (as well as store a "one-way hash" , "salt" the password before hashing, PER_USER_SALT + password - thay are bad solutions)Are you planning the securely storing of th

Re: Storing User Passwords Securely (A.E) planned?

frederikherema1 — Thu, 21 Mar 2013 07:51:22 GMT

The explorer-app is intended as a "demo app", a good place to start. This is the reason why we're not putting in effort for password-encryption because this depends on the required implementation.

I'm not sure how that mechanism works you're suggesting, but if you get a piece of text in the end, that you can store as a password using the API. This would only require changing parts of the Activiti-explorer (user-creation and authentication) which is less drastically than altering user-management. If it's a more complex approach, you'll have to override the identity-stuff, indeed.

Re: Storing User Passwords Securely (A.E) planned?

jbarrez — Thu, 21 Mar 2013 11:32:18 GMT

I have to disagree with Frederik here (that can happen 😉 ). I do believe we should add encrypted password storage + salt hashing to the engine. It requires some changes probably in the command that is used to create a new user (when the password is passed in the User pojo object). So in theory, it would be easy to fix. However, if we want to add a salt, we need a new DB column too, and then some mapping changes.

I actually have it noted down on my todo list for the very near future.

Re: Storing User Passwords Securely (A.E) planned?

frederikherema1 — Thu, 21 Mar 2013 11:36:13 GMT

As mentioned above, hashing + salt is also not "safe enough" for the requirement

Re: Storing User Passwords Securely (A.E) planned?

jbarrez — Thu, 21 Mar 2013 11:42:12 GMT

God point, missed that.

But still we should make it better than it now is 😉

Re: Storing User Passwords Securely (A.E) planned?

udoderk — Thu, 21 Mar 2013 20:48:44 GMT

…
I'm not sure how that mechanism works you're suggesting, but if you get a piece of text in the end, that you can store as a password using the API. This would only require changing parts of the Activiti-explorer (user-creation and authentication) which is less drastically than altering user-management. If it's a more complex approach, you'll have to override the identity-stuff, indeed.

Hi frederikheremans, and thank you for that tips

The explorer-app is intended as a "demo app", a good place to start. This is the reason why we're not putting in effort for password-encryption because this depends on the required implementation…….

i know, that Activiti Stack has two identity packages:
1. ActivitiExplorer-package, containing interfaces:

org.activiti.explorer.identity.LoggedInUser

org.activiti.explorer.ui.login.LoginHandler

And ..0. -
Activiti Engine public stable packages and not stable techical public packages.
I write Engine because thay logically (imho) and "physically" (as JAR file activiti-engine) are part of activiti engine.

The examples of such javas are:

org.activiti.engine.IdentityService

org.activiti.engine.identity.Group

org.activiti.engine.identity.User

org.activiti.engine.impl.identity.Authentication

org.activiti.engine.impl.persistence.entity.UserEntity

activiti.engine.impl.persistence.entity.UserEntityManager

org.activiti.engine.impl.persistence.entity.MembershipEntity

org.activiti.engine.impl.persistence.entity.GroupEntity

org.activiti.engine.impl.persistence.entity.GroupEntityManager

Therefore the identity functionality is a one of core functionalities of activiti (also included to engine). A part of identity functionality is an authentication functionality. The password-encryption functionality is a part of an authentication functionality. Thus, the password-encryption functionality should be a part of activiti-engine. (In form of a few interfaces (imho) ). The default realisation could be implemented in "not stable" public packages of activiti engine. Or it could be implemented into "activiti-explorer" java classes.

P.S Now i found such Shiro plugin in groovy

https://github.com/nickmancol/grails-activiti-shiro-security-plugin/blob/master/ActivitiShiroGrailsPlugin.groovy
with description ..in Spain language(?)