I am retrieving video from an IP-Camera using rtsp using a java web application;
The rtsp url has embedded username/password in the url itself which seems to be quite insecure. e.g. rtsp://user:password#ip/...
Is there a way to to prevent sending the username/password in the URL.
What will be the best possible way to secure the URL?
Username/password in the URL is a way to write url. Rtsp agent will use it to authenticate with basic or digest authentication. So your password will be encoded and transported as a rtsp header.
Given a username and password, you can set them using environment variables like this:
USER=myusername
PASSWD=mypassword
For example, if your camera's IP address is 192.168.0.101, then you can access the camera via its RTSP URL:
rtsp://"${USER}":"${PASSWD}"#192.168.0.101:554
Related
I need to generate a authentication token to secure stream from the Wowza CDN. I like to do this in server base javascript. I'm working on Domino 10 xpages server and working with videojs. Looking for how to get started and any sources that would help.
The Wowza authentication token seams to be an Hash hmac of the information that is needed to authenticate the user.
According to this
https://www.wowza.com/docs/protect-a-wowza-cdn-on-fastly-stream-target-with-token-authentication-in-wowza-streaming-cloud
This is an example how to create these using Javascript
https://www.jokecamp.com/blog/examples-of-creating-base64-hashes-using-hmac-sha256-in-different-languages/#js
I have exposed some rest services in spring, using spring mvc, I have secured the webapp using spring security, that uses bcrypt on the server to encode the password and store it in the datbase.
The user will send the password in the url in plain text under https, And i have written a custom basic_auth_filter to check the uername and passowrd - basically authenticate. I also have set up a firewall that only allows one ip to connect.
Im no security expert, is there anything else i need to, should i encode the username/password in the url.. even though it will be coming via https?
regards
ps. this was a requirement to use username on the url?
Passwords, and all other non-ephemeral credentials, should never be sent in the URL, if for no other reason then because the browsers and other HTTP tools and servers will remember this in history, various logs etc, HTTPS or not, making it trivial to steal by anyone with local access, or even by someone just looking over your shoulder. This is why Spring by default rejects authentication via GET requests.
For this reason, you should move the sensitive parameters to the body of the request (thus requiring a POST).
If your login flow is based on username/passwords, I recommend you use UsernamePasswordAuthenticationFilter as it already encapsulates the logic and best practices for this type of flow.
In general your scheme is secure.
Consider pinning the server, that is validating the server certificate, to ensure the connection is to your server.
The password should not be used other than to authenticate using (in your case) bcrypt.
Re question update: "HTTPS encrypts the query string, only the actual server address portion is un-encrypted. But, the full URL including query string will probably be logged by the server so that has security implication. It is best to send confidential information in a POST.
I am trying to secure an https post service through a username/password authentication (Basic authentication). But so far I am not able to figure out how I can secure my service on the server side and force the username/password combination for the clients. I get that using httpclienthandler/httpclient/networkcredentials you can access the server, but how to force it on the server side and send appropriate unauthorized access errors etc.
Any directions or links using C#?
It seem there is the AuthenticationFilter, what I was looking for..
Here is a good amount of detail here;
https://blockchain.info/api/blockchain_wallet_api
Is it normal to essentially pass your username and password in the URL of an http.post? I'm using the blockchain.info api to send and receive bitcoin transactions on my website. Everything works, but I'm still uneasy about how their service is set up to send out payments. Seems vulnerable?
No it isn't normal, but it will be encrypted as it is sent over TLS.
Usernames and passwords in the address are usually avoided as URLs are often logged on their journey (e.g. by servers, proxies and browsers) but only systems that have a certificate trusted by your client machine can view the full URL over HTTPS (only source and destination will be exposed on the way).
The Base URL for all requests: https://blockchain.info/fr/merchant/$guid/.
The API endpoints are available through HTTPS, so every bit of data you send there (including the URL) is encrypted and protected from man-in-the-middle attacks, I'd say this is safe enough.
We would like to require authentication against an LDAP directory for accessing streaming video content from our Wowza Flash server. The credentials would preferably be entered via the Flash player itself.
Wowza forum posts suggest using examples of MySQL database authentication backend code as a starting point for developing an LDAP auth backend. And examples exist for modifying an existing Flash player to challenge the user for credentials on play. But all examples I've found show the credentials being passed as query string parameters in the connect string, ex:
netconnection.connect("rtmp://[wowza-address]/[app-name]?user1&pass1");
This article suggests a much more complicated solution to avoid passing credentials in the clear, involving authenticating before streaming, setting a cookie that is specially formulated for reauthentication, grabbing the cookie in the Flash player and passing it to Wowza.
Has anyone seen a solution like this that would pass the credentials for LDAP authentication over a secure connection?
Setup SSL for you Wowza server and change your URIs to read
rtmpe://....
then you can use the method you described. Anything you try without SSL is vulnerable to man in the middle attacks.