Project

General

Profile

How to get users' password?

Teemu K
Added over 4 years ago

I'm developing a component that needs to get the users' passwords (to encrypt messages destined to the users out-of-band). I couldn't figure out a way to do that with the AuthRepository interface. I tested adding a getPassword() method to the interface and adding implementations to all the concrete auth repository classes (some of them already have it, just private). This worked, but I want to minimise the amount of changes to the core, so I'm asking if there is a clean way to do it from a component without having to modify the AuthRepository?


Replies (3)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

There is no API to get user's password and this is intentional. We do not want to expose user's password to any other components or plugins where this is not essential. Passwords are for authentication only and are available only to logic dealing with user's authentication.

I do not fully understand your use-case, so it is difficult to suggest you the best approach to your problem, however, I have an impression that you may do this wrong way. You should not need user's password to encrypt user's data. Maybe a better approach would be to use public/private keys or some existing framework such as PGP?

Added by Teemu K over 4 years ago

This is what I suspected. I did consider the security aspects, however, as the components are already running inside the tigase server process, I cannot see a real security gain from not having an API (e.g., I can already read the authentication database credentials from the configuration and get the passwords directly from there, or I can use reflection to invoke the existing private getPassword() method).

The use case is rather complex proof of concept prototype for an esoteric networking stack and not worth going into details. The design in fact does use public key crypto in normal operation, and the use of the shared secret (password) is just to solve the initial key distribution problem (the clients do not have Internet access).

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

With the component, actually, there is one more reason, maybe even more significant. Components in Tigase can be deployed as internal or as external to the main Tigase server. And this is transparent from the developer point of view. So you write a component which may run inside Tigase server or may run on completely separate physical machine. So, there is strong separation between components and one component does not share API to different components. Components communicate with each other via XMPP.

Teemu K wrote:

This is what I suspected. I did consider the security aspects, however, as the components are already running inside the tigase server process, I cannot see a real security gain from not having an API (e.g., I can already read the authentication database credentials from the configuration and get the passwords directly from there, or I can use reflection to invoke the existing private getPassword() method).

Yes, you are partially right. But then you do this all intentionally. Our design of the API is to minimize possibilities of accidental or through bug in the code leak of sensitive data. Therefore, the fewer parts of the code have access to sensitive data the better. I am in favor of strong separation of responsibilities in the code. And, actually, my opinion is that application like Tigase should not have access to user's password at all. The user credentials validation should be done on DB level through logic in DB. Unfortunately SQL and PLSQL is too limited to make it possible in all cases. There is a mode and configuration for Tigase in which Tigase never loads users' passwords from DB and authentication is performed through stored procedures in DB.

The use case is rather complex proof of concept prototype for an esoteric networking stack and not worth going into details. The design in fact does use public key crypto in normal operation, and the use of the shared secret (password) is just to solve the initial key distribution problem (the clients do not have Internet access).

Ok, understand. Let me ask our security expert, maybe he would have some suggestion for you. But, maybe, if this is just a proof of concept, you could use a hardcoded key?

    (1-3/3)