I'm developing a client-server app, the client is an iPhone device that communicants with my c# server. The client and server use a textual protocol that i have designed to exchange messages over TCP sockets. Can someone please give me some guidelines how to add basic security to this app?
At this moment the only security element i have is client authentication with log in username and password. But for example anybody can see and read the messages sent between client and server without any problem...
In the mobile environment the user of the application has more control over the device than you do as a developer. There is no way to hide a secret password or key. You must account for a malicious client, so be careful about the functionality that you expose.
Sending the username and password in plain text is a violation of OWASP a9. You should consider using SSL/TLS or HTTPS.
Have you looked at openssl? SSL are cryptographic protocols that provide secure communication. SSL will prevent others from listen on the stream between your client and server.
One thing more you should do is to validate all server input, to prevent executing malicious code on your server. For example if you have a database where you store user input you should take a look at SQL injection.
Related
I am integrating an application with LDAP in my organisation.
I am implementing HTTPS to send the password from the frontend to my application server, and then forwarding the password from my application server to the LDAP server using TLS. This keeps the password safe in transit.
However there is still the problem that my application server is still able to see the password in plaintext before it forwards the password to the LDAP server.
If I hash it on the front end then the password will not match the password on the LDAP server.
Is this a risk that I need to accept in order to integrate my application with LDAP? Or am I implementing this incorrectly somehow?
My application server is a python flask application and I am implementing LDAP3.
Thanks in advance.
For the question:
Is this a risk that I need to accept in order to integrate my
application with LDAP?
Yes.
The use of SASL Mechanisms which are supported by most LDAP Server Implementations can SASL authentication, this is However, this requires the LDAP Client (DUA) to be able to present an encoded value that contains the SASL mechanism name and an optional set of encoded SASL credentials.
Maybe you could use SASL with a ServerLess Architecture?
Regardless of the technology implemented, any password based authentication would require the user providing credentials which, at some point need to be gathered and therefore subject to this risk.
THe use of OpenID Connect could limit the exposure so the to the OpenID Provider's Authorization Server; but the risk is still present.
WebAuthn eliminates passwords and may be an option.
-jim
When creating any kind of application web,api etc; This days the best practices recommend to secure endpoints by using TLS, but what we can learn from the cloudbleed issue, is that it may not be enough.
Therefore I would like to know what could be done to keep a certain level of security even when TLS is compromised.
For web applications what I currently use is jsencrypt, basically encrypts all data on client browser side before it is sent, but in order to to this I need first to exchange a shared secret (token/cookie) between the server and client, but when dealing with API's that don't support javascript what could be used?
Regarding the exchange of tokens, by instinct it may be obvious to say use OAUTH, OpenID Connect, json tokens , but all of them require or delegate trust to TLS, and again when this is compromised it became useless.
If I am right OpenID could be used without SSL to share a "common secret" by doing Diffie–Hellman key exchange, is there something similar that could be implemented keeping in mind that if TLS gets compromised, easy measure could be taking like revoking tokens or changing "salts" ?
For now I think by following the gpg or rsa (private/public) keys is the way to go, in a way that probably everyone could have access to the public keys but will not be available to see the content of some data signed to a specific user.
But question remains in how to exchange that very first "known secret" between client and server avoiding a possible man in the middle attack considering TLS can't be trusted.
The problem of exchanging the first "known secret" is the same for all protocols, SSL or not. SSL is a public key infrastructure where the basic information that needs to be distributed is the public key of the root certificate of the certificate issuer. The public keys for all ssl certificate issuers are distributed with the browser installation.
Any protocol will depend on some information that is communicated between the server and client in a different channel from the channel where the communication is established. If you don't trust the SSL infrastructure, you will have to send this information by email, postal mail, sms, or by some other means.
However, your problem does not start with the keys neccesary for the encryption libraries you are using in you web application. Your very web application (the javascript files) are also sent from the server to the web browser over SSL. If your SSL communication is compromised by a man-in-the-middle, this man-in-the-middle is also probably able to change the web pages and javascript code that you send to the browser. He could just rewrite your application and remove all encryption code, add new fields and messages for the user, send the user to a different site and so on.
The SSL infrastructure is really a cornerstone in web security, and a neccessity for web applications. Without it, you would have to build a custom protocol for sending encrypted web pages and write a custom browser that would understand this protocol.
With all that said, it is of course possible to add a tiny layer of extra security on top of SSL. You may i.e. create a private/public keypair for each user, send a public key to the user and encrypt all messages from your server to the user with the private key. This could protect against a scenario where a main-in-the-middle is able to listen to the communication but not able to change your messages.
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
During the workflow of my application, there are some "reconfiguration" messages I'd like the user not to be able to see.
I'm going to use SSL for protecting those messages while they are in transit, but I'm not sure if the client can see them before they are encrypted.
Your application is running on a computer the user has full access to. Therefore the user can manipulate your application and application memory and extract everything "secret" you implement.
The same is true for SSL connection. By simply adding a Man-in-the-Middle attack proxy into the network path the user will be able to see everything that is transmitted. Or the user can grab the data unencrypted from the application memory before you send them via SSL/TLS.
Conclusion: Don't rely on data that needs to be kept secret on client side. If it is secret data only process it on server side.
I'm building a Haskell web application for which I need authentication. My organization runs an LDAP server, and I would prefer not to reinvent the wheel. However, when I inspect the source code for LDAP.Init.ldapSimpleBind from the ldap-haskell package, I discover that it calls the C routine ldap_simple_bind_s. As far as I can tell, this API call is going to send my users' passwords in the clear to an LDAP server. Not acceptable.
Have I understood correctly what ldap-haskell is doing?
If so, is there a secure way for me to authenticate my users to an LDAP server from an application written in Haskell?
Passwords must be sent in the clear over a secure connection to an LDAP server that supports password policy checks. Failure to do so will result in the server being unable to manage password history and password quality checks. If the server does not support password policy and history checks, then that server should not be used for non-trivial, mission critical applications. Use either SSL, or failing that, an unsecure connection promoted to TLS using the StartTLS extended operation.
Can you use port 636 (secure LDAP) instead of port 389 to connect to your LDAP server? In this case you would at least have SSL protection.