ACL settings for Password

[JuergeN]

I know it's obvious, but I really want to make sure, we do not forget about it:

The user's password may only be accessable by the user (and the administrator). They must not be viewable/accessable by any other user.

[jri]

For 4.1 I intend to narrow down this ticket to the edit aspect: only the user (and the admin) are allowed to edit the user's password. On the other hand, the SHA-encoded password will be visible to everyone.
This provides apparently no real security, but raises the bar. (The 4.1 backend is not fully secured anyway).
Goal is to release 4.1 very soon. Focus of 4.1 is stability.
Further security issues can be addressed in 4.2

[jri]

Perhaps there is an easy way to address the view aspect as well: the password's view config could be set to "Hidden" but "Not Locked". Thus, the password would only be rendered in the detail panel's form rendering but not in regular page rendering.

[Jörg Richter]

Access Control: fix ACL for user accounts (#375).

A User Account is editable only by a) the respective user, and b) by the creator of the User Account.

Note that a Username is supposed to be fix. But there are still glitches:

• Changing the username when a User Account is selected throws an exception and rolls back.
• Changing the Username topic of the current user directly throws an exception and corrupts the current session.

See ticket 375.

• Changeset: 6eefbd647c9372d3d1910203ff30f4f25dd551fe
• URL: ​https://github.com/jri/deepamehta/commit/6eefbd647c9372d3d1910203ff30f4f25dd551fe

[Jörg Richter]

Access Control fix: edit user accounts (#375).

The direct Username and Password topics are not editable anymore and thus can cause no error.
Only User Account topics are editbale.

See ticket 375.

• Changeset: 5ba57b8fa919e6db78597aa06c27dae8dbec0c4e
• URL: ​https://github.com/jri/deepamehta/commit/5ba57b8fa919e6db78597aa06c27dae8dbec0c4e

[jri]

Current state is:
A User Account is editable only by a) the respective user, and b) by the creator of the User Account.

Regarding the view password aspect it occurred to me that it should not a problem when everybody can see the encoded passwords as the login request does not involve the encoded form but the (unencoded) secret password which is known only to the account holder. The secret can not be derived from the encoded form. So, the encoded password has no value for anyone.
Isn't this the same approach that is (was) used with public readable /etc/passwd file?

From my point of view this ticket is solved.
Or I am wrong?

[jri]

Sorry for my little confusion.

I wrote:

On the other hand, the SHA-encoded password will be visible to everyone.
This provides apparently no real security, but raises the bar.

Here I was wrong.

DM stores and displays the passwords SHA-256 encoded. The login request on the other hand involves the unencoded secret password. So, this is fully secure (as long as HTTPS is used). And is best practice to my understanding.
SHA-256 is a cryptographic hash function. A one-way function. That is, the password can not be derived from the encoded form.
​http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

[JuergeN]

You are wrong! For good reasons all unix and linux distributions moved their passwords into a shadow file quite some time ago. Also from a psychological aspect to many users it just looks irritating for them that other people can see their password, be it encrypted or not. Also I do not want to have to discuss this with them and other developers all the time. Please just fix it and make it visible and editable only for the admin and the user herself if possible, before releasing 4.1. Thx JuergeN

[jri]

Oh, our postings have crossed each other. I closed the ticket before I could read your posting.

Yes, public readable encoded passwords are vulnerable to brute-force-attacks.
However, there is currently no easy DM fix for this. Introducing shadow passwords is just one piece of the puzzle. DM security at large requires a lot more work to do.

• DM Access Conrol mechanism does not even provide a READ permission yet (only WRITE and CREATE). So, Access Control must be fundamentally extended first.
• The ACLs are currently enforced mainly by the frontend. The backend on the other hand only takes some coarse measures. So, a logged in user who bypasses the frontend can perform actions she is not supposed to do anyway.
• We could consider to store the passwords outside the graph (like the ACLs). This would allow us to implement the general READ permission (see above) later on.

All this together is beyond the scope of the 4.1 release.
We will focus on security in a future release.

After a long series of rather backend work I feel the strong urge to invest in the frontend now, the user interface. That is in user-perceivable features.

[JuergeN]

I undestand that the whole ACL concept/design is not really implemented yet. This will become more and more crucial over time. But anyways to satisfy the psychological aspect at least, maybe it's possible to prompt asterisks ("*") instead of the the SHA-encoded password?

[jri]

OK.
The most easy solution would be to not display password topics at all. That is setting "hidden=true" in their view config and suppress them from being listed in the detail panel. So, the user would have no chance to reveal a password topic on the canvas. (Passwords are not searchable anyway.)

The only situation a password would appear (in the detail panel) is when editing an User Account. And that operation is already restricted to the owner and the creator of the account.

I could do this for 4.1

[Jörg Richter]

Access Control: hide password topics (#375).

The Webclient do not display Password topics, neither in the detail panel nor on the canvas.
The only situation a password appears (in the detail panel) is when editing an User Account.

You must reset the DB.

BREAKING CHANGES

Webclient: the RendererHelper?'s topic_list() function does not render hidden topics.
That are topics whose type's view configuration have a hidden=true setting.

Webclient: the TopicType? model class has a is_hidden() function.

See ticket 375.

• Changeset: 0bc5322b4aa4e46d0319321157fbc163a462f085
• URL: ​https://github.com/jri/deepamehta/commit/0bc5322b4aa4e46d0319321157fbc163a462f085

[JuergeN]

Thank you Jörg!