nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Password Security

William Lewis1

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.

Accepted answers

All comments

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

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

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 Lewis1

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?