Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Boron on April 19, 2018, 07:43:12 pm
-
In EA 11 Sparx has changed to a SHA hash of the user security passwords.
Along with that change, the storage location of the user passwords has changed. Before the passwords where in table t_secuser, now they are somewhere else.
Does anybody know where the passwords are stored?
-
Hi Boron, in my 1310 build it seems still to be stored in the table t_secuser.
-
It is true that there is still a column named "passwd", but that is the old password hash that has been used before EA 11.
Somehwere else are the new SHA hashes,but not in t_secuser
-
I found the new password storage.
It is in table t_xref. All entries with name = 'SHA-256' are passwords of users in table t_secuser (passwords that have been created with EA version >= 11).
The guid of a user can be found in t_xref.client.
Maybe this information also helps anyone else :).
-
Ha!
I was gonna say, as a joke, "it's probably in t_xref." :)
/Uffe
-
Yes, definitely useful information. Will add that to the next book release...
q.
-
To Qwerty
Is your book about Scripting in EA updatet to EA v 13.x ?
Regards
Steen Jensen
-
Well, not really. There is no real need for that. It's just that EA adds a few API calls which only get relevant in specific areas. And my book is a general approach to EA's API which has not changed. Anyhow, every now and then I try to update the API description in the book with my own experience on their usage (which quite often is not that positive).
q.
-
Hi there,
I have the same question: we need to integrate EA with our enterprise identity management toolset. Since winauth is no good for all of the use cases, the only way is if we replicate the user passwords from IDM directly into EA repository DB.
Does anybody have any news in this topic? It seems not to be very complicated, the only question is, what obfuscating method is used by EA for the passwords....
Thanks for all in advance!
-
Does anybody have any news in this topic? It seems not to be very complicated, the only question is, what obfuscating method is used by EA for the passwords....
Not obvious enough? The Name of the xref is accurate. It's a SHA256 hash.
-
Eve,
No, not really :( Unfortunately the question is a little bit more complicated.
Please let me analyse the question short
Actually an SHA-256 hash is 32 bytes long, but the values in column xref.supplier are 44 bytes long. Okay, quite simple: the values are base64 encoded.
BUT! If I use the Password "Password",
...It's SHA-256 hash (hex) is: E7 CF 3E F4 F1 7C 39 99 A9 4F 2C 6F 61 2E 8A 88 8E 5B 10 26 87 8E 4E 19 39 8B 23 BD 38 EC 22 1A
...with base64 encoding this 32 bytes i will come to: 588+9PF8OZmpTyxvYS6KiI5bECaHjk4ZOYsjvTjsIho=
...unfortunately xref.supplier contains: R9Bqf629Fwrn3K7mCXcXcQzDJ/+AB2MPUr5iBTq5LK4=
As you can see, the value in xref.supplier is different from the SHA-256 hash of the password. So, the hashed string MUST be different from the password. The question is: How different?
If I create two users with the same password "Password", the field in xref.supplier will contain different values for the two users: it means, the password must be "salted" with some user details. To find out how it is salted, seems to be near impossible.
So, I must say: NO, it's not obvious enough!
Regards,
Gergely
-
I doubt they publish that. Since if so it will be easy to create a new admin password and replace it. Alas, since having direct access to the DB anyway, any "security" measures are pointless.
q.
-
Shh!
Don't start pointing out the complete absence of anything like security in this product.
All that will get you is shat on from a dizzying height.
/U
-
I was sent to hell eons ago.
q.
-
But it's a good thing they started salting the hash. They didn't do that a few versions ago.
That at least makes it less likely to figure out someones password with a rainbow table.
It doesn't really make EA any more secure, but since people tend to re-use passwords, being able to figure out passwords from the hashes is a significant security risk.
Using Windows Authentication (or OpenID? Never used that one) of course much better as EA doesn't have to do any password encryption anymore.
Geert
-
Shh!
Don't start pointing out the complete absence of anything like security in this product.
All that will get you is shat on from a dizzying height.
/U
Agree with you. Security is clearly one of EA's main weakness. I am using ea since its version 9, and i ask Sparx every year to develop enterprise grade autnetication method.
Sparx Systems should realize, that their product is also used by large enterprises, where identity management and security is a key factor of working. It would not be a very hard challenge to develop an ldap based authentication in 2020!
I think, Sparx's luck is, that enterprise clients realize this weakness of EA tipically only after the purchase...
-
I think, Sparx's luck is, that enterprise clients realize this weakness of EA tipically only after the purchase...
If at all.
q.
-
I'm not sure I'm following.
You can use
- username and password
- Windows Authentication
- OpenID
The last two seem like enterprisey enough no?
Since v15.1 you can also simply link your EA security groups to AD groups, without the need for double maintenance of users.
For larger clients this is a major improvement.
Geert
-
Hi Geert,
I am of a different opinion
-Windows Authentication: yes, it's a good stuff. But it is strong restricted, where and how you can use it, and (to tell the truth) I'm afraid EA's WinAuth is not a really well-designed and fully elaborated solution (!!!it's just my feeling, not a fact!!!!)
- OpenID is dead (and it is questionable if it was ever alive) :)
Cheers, 8)
Gergely
-
Once again: EA security is NO security. It's some accidental deletion prevention (which might be ok if applied the right way). But in no way this has to do anything with security. Blocking the main entry with a panzer and having the backdoor completely unsecured - well, would you trust that bank your valuables?
q.
-
I don't entirely agree with you on that.
We use WVD (the new remote desktop) to publish the application and SQL server as database. All access is to WVD, SQL Server and Enterprise Architect is set to Windows Authentication, this this is really single sing on.
The way we do it we have Active Directory groups in different levels to control access to the application and its functions.
- EA Application Group (these users get the application published wia WVD (the new remote desktop))
- EA RepositoryA Group (these users get read/write access on the database level )
- EA RepositoryA Admin
- EA RepositoryA Read/Write
- EA RepositoryA Read-only
- EA RepositoryB Group (these users get read/write access on the database level )
- EA RepositoryB Admin
- EA RepositoryB Read/Write
- EA RepositoryB Read-only
The entire user management is now a first level service desk process (with some self-service automated processes as well for approved accesses)
All we need for a user to have access is that the user in the right Active Directory group. If the user is no longer in the group the access is actomatically revoked.
I consider all of that a major part of Security.
Now once you are part of the database read/write group, you can in theory do anything.
The Admin, Read-Write, Read-only EA specific groups are more there to protect the users against themselves.
If we don't want regular users to do xmi import, or create their own stereoypes, we can restrict that in these groups.
I think mostly this is sufficient.
Is it going to stop someone with mall intent, that has access to the database, to wreak some havoc? No, but that why we have backups etc..
Is it enough to be useful in "normal" (99,9%) cases? Yes
With a setup like this I'm no longer embarrassed to present this to the security responsible in the organization.
Geert
-
Taking a deep breath and wading back in...
The entire user management is now a first level service desk process (with some self-service automated processes as well for approved accesses)
All we need for a user to have access is that the user in the right Active Directory group. If the user is no longer in the group the access is actomatically revoked.
I consider all of that a major part of Security.
Absolutely. Getting rid of obsolete user credentials is very important, and being able to do manage access using nothing but standard OS tools is also very important.
Now once you are part of the database read/write group, you can in theory do anything.
The Admin, Read-Write, Read-only EA specific groups are more there to protect the users against themselves.
If we don't want regular users to do xmi import, or create their own stereoypes, we can restrict that in these groups.
I think mostly this is sufficient.
Is it going to stop someone with mall intent, that has access to the database, to wreak some havoc? No, but that why we have backups etc..
I think you're confusing security with robustness there. Security is not primarily concerned with continuity and things breaking, it is concerned with preventing unauthorized access (leakage) and malicious updates (misinformation).
You can delegate control over access to the information to the DBMS and the AD, which is good. But you don't have to, and from a security perspective, that's bad. It means you have to instruct IT do do it right while leaving them the option to do it wrong, and that adds another link in the chain.
It's also massively annoying that EA chooses to refer to its user roles, which restrict access to functionality but not to data, by the term "user security." It's not security. It's nothing to do with security. So right out the gate that's something you have to explain to the IT security people. You might not be embarrassed by that -- I am. ;)
/U
-
I agree that the term "User Management" would have been better then Security
Geert
PS. With PCS and SQL Server or Oracle, you can apparently restrict access to data as well. This works with the row level security on database level.
Never tried it myself, but might be interesting if you have a use case for it.