i want to authenticate a connection (VPN) agains a RSA Server.
The Source (VPN Client) speaks MSCHAP, but the RSA only understands PAP.
So my idea was to use an Freeradius as Proxy to translate/convert the MSCHAP Request to PAP and ask the RSA Server for Authetication.
But i can't find a way how to do this.
It’s not possible. You can’t retrieve the plaintext password from the MSCHAPv2 response as it has undergone multiple hashing rounds by the time it is received by the server.
You can’t retrieve the input text to a hash, the best you can do is generate a collision (input text that produces the same hash output), and that doesn’t help you here due to the time in which you’d need to do it.
Related
Just a simple question:
what is the difference between a request and a command in protocols like HTML or SMTP?
Can it be that requests await a response?
Or that one is from the client side and the other from the server side?
Thanks in advance!
Similar to http, smtp requests can contain multiple commands e.g. the TLS command to enabled encryption
E.g. HELO, BYE
Ftp is similar to Smtp, where a single connection (request) exchanges multiple commands (PASV... EXIT) before the connection is closed.
The main difference is the request response for http can usually be visualized as 1 request to 1 response however when you look at how the TLS encryption is applied over http you then see similar commands being exchanged between client and server before the final response is returned to the client.
In short http separates the noise of the commands by encompassing them into the header portions of the request and response.
An example of http commands without encryption would be chucked transfer encoding where the server send a part of the response after the headers in chunks which must be put back together at the client side.
I couldn't find exact answer.
In similar topics, people say that without Private key you can't view HTTPS response, but I am surprised, why key needed at all? For example, when browser requests https://example.com, it can read view it's html output.
And I want the same in WireShark (one of my program reads response from https://example.com and want to view just that page's outputed HTML). However, I can't understand why Private key is needed with this simple task?
If you didn't need to know the private key, an attacker wouldn't need it either – then any HTTPS traffic including login information, credit card numbers, photos, etc could be read by anybody that is on the same network as you (somebody listening to wi-fi traffic), or anywhere between you and the server (ISPs). This would be a disaster.
HTTPS (or more specifically TLS) was created for this purpose – to be able to communicate with remote parties securely without having complete trust in every single node on the way to the remote party. It relies on public-key cryptography, which makes it so that it is easy to encrypt messages with the public key, but extremely difficult (or practically impossible) to reverse the encryption without knowing the private key.
A browser which communicates with a server via HTTPS creates a link based on keys exchanged securely. Only the server and the browser know these keys, and so only the server and the browser can send and receive messages to each other.
Wireshark, even if it is running on your computer, is not running as a part of your browser and hence does not know the keys that the server and the browser agreed on. So it is impossible for it to read the traffic.
It may be somewhat surprising to know that even if somebody (Wireshark) can read all the data your browser exchanges with a server, it will not know the keys that the browser and server agreed on.
Traditionally, secure encrypted communication between two parties required that they first exchange keys by some secure physical channel, such as paper key lists transported by a trusted courier. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Diffie-Hellman key exchange, Wikipedia
I have wrote a simple Django web service that provides an iOS app with JSON information containing download links.
I don't mind the JSON information to be clear text, but when the user logs in, I would like him to login with his username and password, then he would probably get some kind of key for future requests which I understand that can be sniffed out. For that first interaction, how could I protect the password and username from being clear text and sniffed?
I have decided I wanted to use a symmetric encryption to encrypt my password and have that key both on client and on server. (yes, I am aware that if someone goes to the trouble of binary hacking my app and sniffing packets from a customer he would be able to get the password in clear text, it's just not a likely concern).
I would like to use some kind of encryption that I can easily do in iOS and than decrypt in my django server. anyone has a suggestion on how to do that?
If you want to encrypt the communication between your django server and the client then you can use secure HTTP rather than plain old HTTP. This is done outside django, and is configured at the web server level. For example, if your django app is ran by a WSGI server like gunicorn or uWSGI which in return is handled by nginx (this is a common setup) then you would configure your nginx server to accept only secure HTTP requests and forward any standard http request to https. This way you can ensure that everything the client sends to the server is encrypted on the browser prior to sending. Similar setup is done with Apache, though I personally have never used Apache with django.
Since the OP feels that HTTPS is not a viable option a modification of CHAP Challenge-Handshake Authentication Protocol for the initial key creation might be an option.
I'm trying to make a secure protocol between an iPhone app and an Arduino server. The goal is that the iPhone app makes a request to an Arduino server and the server only processes it if it has the proper credentials of one form or another. I'm not really sure how to approach this problem. Any suggestions are much appreciated!
Unfortunately there are no truly secure communication options available on Arduino. The basic problem is that SSL libraries have not been ported to this platform, partly owing to the fact that the 8-bit processors the platform is built around are not very powerful. Having said that there are some things you can do, but you'll have to do them yourself:
Basic access authentication is a very insecure method of controlling access to HTTP pages so it isn't recommended. Digest access authentication, on the other hand, employs one-way cryptographic encoding (hashing). It only requires MD5 library, which, is actually available for Arduino. What you'll need to do is modify the source code for the Web Server class to support digest access authentication: AFAIK it does not support it out of the box.
If this seems to difficult, you could implement something fairly basic (and not very secure, but better than nothing) yourself. It might look like this:
The first GET request comes in from a client
The server responds with "not authorized" response, embedding in the response a token which is related to (perhaps a hash of) the requesting IP address. You could make the original timeframe part of the hash as well, and give such tokens a limited lifetime.
If the next request from the same IP address includes a hash based on some secret code + the token sent, the next request is honored.
Now this will not protect you from IP address spoofing, and many other things I probably haven't thought of. However, it will give you a modicum of security (and a tiny bit of security through obscurity, if you believe in this sort of a thing). You could ask for (slightly) more elaborate schemes on superuser
You might be able to just use authenticated messages built on shared secrets. The message will contain [at minimum] a message type, message body, timestamp, and message digest. You create the digest by HMACing the other stuff with a shared secret. (Type HMAC Arduino into Google for libaries and code.) The message is sent over TCP or UDP (i prefer it). The Arduino computes digest of message, checks it, validates data, and then acts on message.
One thing I like to do is implement port-knocking or something at the network layer in front of the application server. This prevents unwanted traffic from reaching the custom (and possibly vulnerable) command server. This can be done stealthily (see Silent Knock) or obviously. The network protections can also be implemented by a dedicated device that does the heavily lifting and disqualifies much rogue traffic before it reaches the Arduino.
I am using the indy components to implement emails in a delphi application. I am specifically using the TidSMTP component. I need to effectively support all major email servers. I use Mozilla Thunderbird as my email client and am comparing the smtp properties with those in the TidSMTP component. I have attempted to find documentation that describes the relationship between the TidSMTP properties, but have not been able to figure it out.
Can someone explain how these compare and what they do:
In Thunderbird:Connection Security: (None, STARTTLS, SSL/TLS).
In TidSMTP.UseTLS (utNoTLSSupport, utUseImplicitTLS, utUseRequireTLS, utUseExplicitTLS)
In Thunderbird:Authentication method: (No Authentication, Normal Password, Encrypted Password, Kerberos/GSSAPI, NTLM)
In TidSMTP (username, password, with useAuthentication method)
I also see other TidSMTP properties: UseEhlo, UseVerp, UseNagle. Do I need to be using these? What do they do?
When using STARTTLS, the server's listening port is initially unencrypted upon connecting. When a client connects, it can send an optional STARTTLS command to the server, if the server supports it, to dynamically perform the SSL/TLS handshake at that time. This allows legacy non-SSL/TLS clients to continue connecting to that same port, while allowing newer SSL/TLS-enabled clients to use SSL/TLS if available on the server. This corresponds to UseTLS=utUseExplicitTLS in Indy. You need to set UseEHLO to True in order to use UseTLS=utUseExplicitTLS, as the EHLO command is how TIdSMTP discovers whether the server supports the STARTTLS command or not.
When using SSL/TLS instead of STARTTLS, the server's listening port is always using encryption and the client must initiate the SSL/TLS handshake immediately upon connecting before any other data can be exchanged. This corresponds to UseTLS=utUseImplicitTLS in Indy. There is no STARTTLS command used.
For authentication, TIdSMTP has two options - the old (and unsecure) AUTH LOGIN command that is defined by the original SMTP spec, and SMTP extensions for SASL-based hashing/encryption algorithms (Kerberos, GSSAPI, NTLM, etc are implemented as SASL algorithms).
To use SASL, set TIdSMTP.AuthType to satSASL and then fill in the TIdSMTP.SASLMechanisms collection to point at separate TIdSASL-derived components for the algorithms you want to support in your app. Indy has native SASL components for DIGEST-MD5, CRAM-MD5, CRAM-SHA1, NTLM (experimental), ANONYMOUS, EXTERNAL, OTP, PLAIN, SKEY, and LOGIN (SASL wrapper for AUTH LOGIN). If you need another algorithm (Kerberos or GSSAPI, for instance), you will have to write your own TIdSASL-derived component. For algorithms that use Username/Password, the values must be assigned to a separate TIdUserPassProvider component that is then assigned to the SASL components (the TIdSMTP.UserName and TIdSMTP.Password properties are not used with SASL). The more SASL algorithms you support, the wider the number of servers you will be able to support.
For servers that still support AUTH LOGIN, it can be used either by setting TIdSMTP.AuthType to satDefault (and optionally setting TIdSMTP.ValidateAuthLoginCapability to False if the server supports AUTH LOGIN but does not report it in response to the EHLO command) and then filling in the TIdSMTP.UserName and TIdSMTP.Password properties, or by including the TIdSASLLogin component in the TIdSMTP.SASLMechanisms collection.
UseVerp and UseNagle have nothing to do with security. VERP is an SMTP extension for detecting bouncing emails due to undeliverable errors. Nagle is a networking algorithm for optimizing network data packets.