Password Security

[William Lewis]

Hello

We are currently evaluating Crowd on Linux with postgresql back-end. We would like to use it to authenticate/authorise users of Jira, Confluence,Stash and the Calendar - as well as some of our own web-based systems. We would like to know how you secure the passwords in the code and DB. For instance:

How do you mitigate against a man-in-the middle attack?

Could someone obtain the passwords if they had access to the crowd DB?

Any further info regarding security would be useful. Apologies if this has been covered elsewhere.

[Caspar Krieger]

I'm a developer on Crowd; the information provided by Tiago is correct, but I'll elaborate a bit.

For "internal directories", we use one of a number of password encoding schemes (user configurable, and you can provide your own via a plugin if so inclined). The default is "Atlassian Security", which is currently a dumb wrapper around Bouncy Castle's implementation of PKCS 5 version 2 (aka PBKDF2), using a random 16 byte salt, 10,000 iterations, and generating a 256-bit hash as the final output. We wrap it so that we can easily upgrade "set it and forget it" customers to a more secure scheme if the current underlying scheme is found to have a vulnerability.

Application passwords (used by applications such as JIRA and Confluence to authenticate with Crowd) use the same scheme.

For LDAP directories (i.e. cached, uncached, and delegated authentication LDAP directories), we never store user passwords. Each time a user tries to authenticate with Crowd in the context of an LDAP directory, Crowd the application authenticates to the LDAP directory as that user, which necessitates sending the user's password the LDAP directory. If the network between Crowd and your LDAP server is untrusted in your security model, we highly recommend configuring Crowd to use LDAP over SSL (LDAPS) for talking to your LDAP server.

Other information which is relevant to Crowd's security model is that applications configured to authenticate to Crowd are considered to be trusted parties; Crowd ensures the directory to application mapping abstraction doesn't leak, but it does not ensure that (for example) one application isn't accidentally DoS'ing another application.

[William Lewis]

Hello Caspar

Thank you for your response. Would you be able to elaborate on how "Crowd ensures the directory to application mapping abstraction doesn't leak"? Do you have any papers/documents on the Crowd security model that we can look at? We would very much like to use Crowd for SSO, not only for Confluence, JIRA etc, but also for various in-house web applications that we are developing, but we need to be able to understand/describe the Crowd security model to our end-users.

[Caspar Krieger]

By "Crowd ensures the directory to application mapping abstraction doesn't leak" , I mean that applications will only know about directories which have been mapped to it in the application mapping (relevant docs on application mapping, and some info on Crowd directory vs application concepts here).

We try to keep our docs relatively comprehensive instead of publishing papers which get out of date, so I suggest looking at those links. I watch for new Crowd questions on both this site and the docs, so feel free to comment or ask more questions if anything is unclear.

[Bryan Karsh]

Hi Caspar -- had a couple questions. If Crowd doesn't store the passwords from ldap, how does caching work? In other words, what is the user's password checking against? Or are you saying that for ldap, there is no caching?

Also, when I look at the cwd_user in the database, there is an encrypted string in the credential column for ldap users. An example is "pX2FDrYQ" -- if this isn't a password, what is it?

[Caspar Krieger]

There is caching for LDAP directories for users, groups, and memberships (in the form of fetching all those periodically and storing them in Crowd's database). However, user passwords are never fetched (and the same applies to the password hashes if the passwords aren't being stored in plain text, as is usually the case). Instead, to check a user's password, Crowd takes the password that the user provided, and sends it to the LDAP directory to check (or rather, as I mentioned earlier, what Crowd actually does is try to authenticate to the LDAP directory as the user using the password that the user provided).

(Incidentally, connecting Crowd - or JIRA, Stash, or Confluence - to a remote Crowd server works the same way.)

There is a credential column in the cwd_user table, but it should only store actual (hashed) credentials for users in internal directories. For remote directories, it stores dummy data of "nopass" (if you're skeptical, you can download the source and search for occurrences of the text "INTERNAL_USER_PASSWORD"). If you have found some way to get the password (or hash) of an LDAP (or remote Crowd) user into a local Crowd instance, we would consider that a bug (which you can report at https://jira.atlassian.com).

[Bryan Karsh]

Hmm. does this mean then that there is no real login authentication caching when using crowd or ldap? For some reason I thought that if there was an outage involving crowd or ldap -- if the caching was set high enough, a jira user for example wouldn't immediately notice. I'm thinking out loud here, but it sounds like if you are logged in already, your user groups would persist in a cache, so that you may not notice an outage... but if you tried to log in, it would fail, since you have to contact crowd/ldap for password?

Or is the above scenario only for ldap users? If a local directory is cached in an application, and crowd goes down, it seems like they would be able to use their password still?

[Caspar Krieger]

Your conclusion is correct - if the remote Crowd server or LDAP directory goes down, new users will not be able to authenticate to applications connected using the down services. But existing users will keep their login session for a time, because (for at least some of our apps) there's code to trust the user's token cookie if matches the token stored for them in the tomcat session, and yes their groups and memberships would still be available in the cache that each application maintains.

The above scenario is for LDAP and remote Crowd users - LDAP directories (non-delegated) and remote Crowd directories share most of the caching and syncing logic (incremental sync support being the exception). Only users in a local (aka internal) directory will still be able to have users log in, because their (hashed) password is actually in Crowd's (or JIRA's, or Confluence's, etc) database.

[Bryan Karsh]

Thanks Caspar -- that helps a lot in my understanding of Crowd. Much appreciated!

[Emmanuel Koch]

Hello, This answer is very interesting, and I have a question linked to it: I have integrated my own web apps with crowd. What I would like to have is an authentication fallback in case crowd is down. I plan to have a script to copy/sync the user password from the crowd database to my own application database. Once this is done, how can I validate a user password (send by my webapp) against the crowd encrypted one? Do you have any piece of code I could reuse?

[Caspar Krieger]

@Emmanuel Koch I have an answer for you; would you please ask your question separately and tag it with the "crowd" topic? Then I'll see it and answer there.

[Caspar Krieger]

(A separate question makes it more likely others will find and benefit from the same information.)

[Emmanuel Koch]

Ok, this is done: https://answers.atlassian.com/questions/9390082/how-to-validate-a-raw-password-against-crowd-encrypted-ones Thanks in advance!

[Tiago Comasseto]

Hi William,

I can't say much about attack protection as I don't have extensive knowledge in this area, but regarding Crowd database, it stores only the passwords of internal users and it's encrypted as you can see in the example bellow:

mysql> select user_name, credential from cwd_user limit 2;
+-----------+---------------------------------------------------------------------------+
| user_name | credential |
+-----------+---------------------------------------------------------------------------+
| admin | {PKCS5S2}siTdcDkChqeSDGVnIMILINUGSzhublIyp1KDvI0CJQ3HuQurEHyN7itWI6rpIzN4 |
| testuser | nopass |
+-----------+---------------------------------------------------------------------------+
2 rows in set (0.00 sec)

The other user in this query is coming from an LDAP directory, as you can see the password of LDAP users is not stored into the database. All password validation is done directly against the LDAP server itself.

Cheers

[darylchuah]

Hi William

Referring to your overall question, perhaps you can have a read on the following documentation on:

• Crowd Security Advisories and Fixes

I am not sure whether it will actually answer your question all however the above page will gave you an overall and rough idea on how Atlassian handles security vulnerability and fixes/patches on Crowd itself.

Hopefully it will help a little ;)