How to specify rtsp authentication credentials on client side with gstreamer? - gstreamer

The gstreamer RTSP server supports basic username-password authentication (example). On the client side, the gstreamer playbin element supports playback from an RTSP server, like this:
playbin uri=rtsp://127.0.0.1:554/test
Is there a way to specify credentials (a username and password) on the client side when connecting to the stream?

From gst-inspect-1.0 rtspsrc:
user-id : RTSP location URI user id for authentication
flags: readable, writable
String. Default: null
user-pw : RTSP location URI user password for authentication
flags: readable, writable
String. Default: null
EDIT:
Oh playbin..
Does it not accept user and password from URI? E.g:
playbin uri=rtsp://user:password#ip.address/stream

Related

Encryption of a Password send over HTTPS

Good day,
I am very new to database/application/connection security and would like some help on a project.
Let me explain my environment :
I have a username A and password A being saved in a database (A) on a local machine.
Password A is being stored using a type of hashing algorithm with salt A.
I am sending the credentails (Username A and Password A) via a HTTPS SOAP Call to a webservice sitting remotely.
Apon receiving Username A and Password A the webservice validates those credentials to a table sitting in database (B) local to the webservice location.
My Problem : If someone gets access to database A and extracts the hashed passwords they can use a SOAP request to connect to the webservice. This means that my security is null and VOID.
I have to possible solutions :
SOLUTION 1 : Before sending password A to the webservice, I decrypt it and send it over plaintext via the Secured HTTPS connection. The webservice will then encrypt it again when validating agains the hash stored in database B.
SOLUTION 2 : Before sending password A to the webservice, I do a second encryption to that existing hash. When arriving at the webservice, it is decrypted to expose the hash which is .then validated against database B.
My Question : Is any of the 2 solutions above, best practice. If not, what would be a best practive solution for this scenario.
Kind Regards
Just a few notes
there is difference between hash (one way, non-reversible) and encryption (reversible). You cannot decrypt hashed value.
I will assume you are working with service credentials, not user's identity credentials
Here I will assume you are talking bout
SOLUTION 2 : Before sending password A to the webservice, I do a second encryption to that existing hash. When arriving at the webservice, it is decrypted to expose the hash which is .then validated against database B.
The hash effectively becomes a password, it doesn't add any security to the solution
SOLUTION 1 : Before sending password A to the webservice, I decrypt it and send it over plaintext via the Secured HTTPS connection.
There are several standards to authenticate the SOAP WS client, using simple credentials it's WS-UsernameToken. Effectively the client sends its username and password plain, relying HTTPS to handle the channel security.
My Problem : If someone gets access to database A and extracts the hashed passwords they can use a SOAP request to connect to the webservice
One the password is hashed, you won't be able to decrypt it, but as well you cannot use the hashed value as a password. Otherwise you will get the "solution 2" and you are using the hash as a password.
Indeed, this is generally a problem. You may search other questions, how to store service credentials locally. The whole problem is - you need to store the credentials. In my experience the best you can do at least make retrieval somewhat harder, e.g. encrypt the service passwords so they are not stored plain in the database or config files. At the end the client application needs the encryption key somewhere to decrypt the credentials. The key needs to be protected as well.
If you are dealing with user credentials (user identities), do not store the user passwords at all at the client side, there are other ways how to authorize user actions (access token, jwt token, ..)
If you are using xml based SOAP you can use WS-Security to encrypt the password and sign your request data so that the integrity and security of your password is ensured, and the send the data over https.
For storing passwords you should use irreversible crypto hash like sha2, at server you will decrypt the password, create sha2 hash and match it against the one from database

Qt Authentication users with QTcpServer (with username and password)

I want to write a chat program with login page.
I want to send request from client to server with username and password, then server receives, verifies and then responds to client.
Can anyone please guide me of what QT class should I use or can tell me some ideas of how to access them?
With QTcpServer, you can set up authentication for client with some basic username:password pair at the start. As soon as the connection is established, ask or wait for the username:password to be sent over to the Server. Verify it. In case of invalid data or timeout, close the connection.
As far as the login page is concerned, you need to host that on the Server and you'll be dealing in HTTP protocol instead of TCP. Take a look at QHttp. That'll get you started.
For Qt, there are other options too. You just have to lay down your requirements and find the one that might fulfill those e.g. Wt.

How can I connect to WSO2 Message Broker with an MQTT Client?

I have installed WSO2 IOT Server and I am trying to understand it...
My principal objective is to make some IOT Device send data through MQTT.
But I can't even connect to MQTT with Mqtt.fx... I am using tcp://localhost:1886 as the broker URL address even though in the broker.xml config file it's said that the port is 1883 - It doesn't work either. I uses admin as the login and password, but I get an error:
[2017-03-31 10:40:07,861] [IoT-Broker] INFO {org.dna.mqtt.moquette.messaging.sp
i.impl.ProtocolProcessor} - Lost connection with client 5354d06fb5694b5cb65f07c
f3c62fa23
[2017-03-31 10:40:07,863] [IoT-Broker] WARN {org.dna.mqtt.moquette.messaging.sp
i.impl.ProtocolProcessor} - MQTTAuthorizationSubject for client ID 5354d06fb569
4b5cb65f07cf3c62fa23 is not removed since the entry does not exist
What am I doing wrong ?
Second issues, I can't access to WSO2 Message Broker management... I get an Error 403 Forbidden when I use https://localhost:9446/carbon. And I don't know how to access the WSO2 Message Broker when I am on the WSO2 IOT Server management page. (https://localhost:9443/carbon which works)
MQTT broker in wso2 IoT Server has a pluggable authentication and authorization, by default it comes with an OAuth based authentication, where it uses an empty password and uses an OAuth token for the username. You can generate a token by following the docs in https://docs.wso2.com/display/AM200/Password+Grant.
Implementation of this extension is explained in [1] and [2].
[1] https://medium.com/#ayyoobhamza/authentication-and-authorization-extension-for-mqtt-wso2-message-broker-2495fb2fa56e
[2] https://medium.com/#ayyoobhamza/oauth-authentication-and-authorization-with-mqtt-for-iot-devices-a42019187a05

REST Authentication with Username and Password to receive Token

I have a dataprovider with a REST service. They said that the authentication goes as follows:
1. Username and Password are passed in the request header
2. If the authentication is successful I get a token which I have to store and use this token to make further requests.
Now I started reading into REST Authentication and just do not understand what kind of authentication they use. I guess I have missunderstood something, so please correct me.
There are three kinds of authentication
1. Basic Authentication (sending username and password base 64 encoded in the header)
2. OpenID (here I send my username and password to a provider to receive a token)
3. OAuth (The caller is identified with a trusted token to let application call another application on a end-user's behalf without requiring the calling application to store the users's username and password)
I cannnot see, where to classify my providers method. 1. I am not sending UserName Password everytime. 2. I do not use a provider, 3. I am not doing application calls and do not use only tokens. Could anyone help me here?
When you send username and password to provider if correct, provider will create a token for this user and this token will be sent to you by provider.
After this, you can use this token in any session and you can check only this token for expiration, you do not have to send username and password everytime.

ADsOpenObject password encrypted?

I'm getting some details from Active Directory via LDAP url, for this
ADsOpenObject in msdn library:
hRes = ADsOpenObject(pwszBindingString, pwszUSER, pwszPASS, ADS_SECURE_AUTHENTICATION,IID_IADs, (void**)&iads );
I'm having doubt about whether the given password will be encrypted or not while connecting the Domain Controller
This MSDN page says
Caution If a user name and password are specified without specifying authentication flags, the user name and password are transmitted over the network in plaintext, which is a security risk. Do not specify a user name and password without specifying authentication flags.
You are using the ADS_SECURE_AUTHENTICATION flag from the ADS_AUTHENTICATION_ENUM, which means:
Requests secure authentication. When this flag is set, the WinNT provider uses NT LAN Manager (NTLM) to authenticate the client. Active Directory will use Kerberos, and possibly NTLM, to authenticate the client. When the user name and password are NULL, ADSI binds to the object using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread represents.
Both NTLM and Kerberos are protocols that "encrypt" the password. If you want the username encrypted as well, then you need SSL (which requires that a certificate server is setup for the domain).
You can always use a packet sniffer to verify that the information is encrypted.