For educational purposes I'm implementing a simple remote shell program, and I'm trying to wrap my head around how to make it somewhat secure. The first idea I had was to just require a password. If the client sends the password, it runs, if not, it quits. Then, I applied a simple hash function to the password, but I don't think this really makes it any more secure. In either case, if the packets are intercepted, an attacker could just extract the password or the hashed password. What can I do to make this more secure Is there a way to use password/hashing that is safe from basic packet interception? I know that ssh uses public/private keys to encrypt and decrypt, but that is more advanced than I need.
How about a challenge/response with digests? Say the server knows the password is "blah".
The client connects, and authenticates:
Client: Let me in!
Server: I give you the challenge "12345", a number I generated just now!
Server remembers that they gave the client "12345".
Client wants to authenticate with "blah", so they add it to the end of the server's challenge, and then calculates the SHA-1 of the result "12345blah".
Client: My response is "6910972fb3148a63df7fda34bd6fccf3013d8d93"!
Server knows the password is "blah", and issued the challenge "12345" to this client—hence it calculates the SHA-1 of "12345blah", and produces "6910972fb3148a63df7fda34bd6fccf3013d8d93". This matches the client's response so …
Server: Access granted!
Important notes:
The server MUST be the one to choose the challenge. If the client gets to pick, then an attacker could just intercept one authentication attempt, and repeat the same challenge and response as that valid user.
The fact that the server picks a different challenge every time means an attacker can't replay authentication. This means the server needs to store the challenge against the client's connection or session somehow, since you'll need it when they respond.
You may want to use something stronger than SHA-1 (it's a little broken IIRC). You may also want to do something other than just appending the password to the challenge, as the security properties depend on the underlying digest function.
I demonstrate this with a password "blah", but the nice thing is now, you can replace "blah" with the hash of "blah". The server never needs to store more than the hash, and then the client just hashes their password first before combining with the challenge and calculating the digest.
Related
I need a serverless communication between a server(less backend) and a client. The client asks for a token. When the client makes a request with this token, the backend generates a new token and sends it back to the client. When the client tries to make a request with a previous token, the backend rejects it. I don't want the backend to keep track, either in ram or in a database, a whitelist or a blacklist of valid/invalid tokens. The backend is allowed to have a static lookup table or/and a static rule/algorithm to perform this logic if needed (to use the information inside token's payload).
So, is it possible to achieve something like this ? Is there a way to apply certain kind of information inside each token to know wether you have accepted it once or not ?
In your scenario the server is stateless (at least regarding authentication) so you cannot use the state of the server to discriminate if a received token is already used.
Also the moment you generate the token it is before it's first usage, so you cannot inject into it anything that tells if it was used or not: simply you don't have that information at that time of course.
So basically if your only information containers are these two (stateless server and self generated token) the answer is no no matter how it is done; simply there is no place where this bit of information (is this token last one or not) can be placed in the moment the information is generated (at the first usage time).
Theoretically speaking you can send this information to a third party entity and ask it back when you need it.. ..but this is just cheating: if you are not accepting a DB or RAM or filesystem storage, I suppose that sending this information somewhere through an API or else is just an excluded option as the other ones.
May be you can try TOTP, https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm. This is the same algorithm used for MFA.
Here is the python implementation, you can find implementation in other languages as well.
https://pypi.org/project/pyotp/2.0.1/
Backend:
Create a random key and save it static database.
When client request for token create a token(+base64 conversion) using random key and send back to client.
When your server gets the token(-base64 conversion). Using the same random key verify the received token.
The totp algorithm will ensure that the old tokens are not valid.
You token is usually valid for 30 secs. so you may want decide on managing the validity of tokens.
I need to send all data with some token (rendomly generated), so that server side script can recognize it secure.
As well as, I need to encrypt username-password also for security purpose.
My client want strong security, and I never done it before. So please any one suggest me!!!
I want to login with a file that contains digital certificate of someone, first registers with certificate contents that is base64 format, and when registering it will encrypt the content of certificate and save into database and when login with this file, i want to login with that data matched by decrypted way, pls help how to do this? And also when i encrypt each time file content saved with different characters, is it possible to save 3323 characters in database? pls help.....
// controller
$main_file = $request->file;
//$con = $main_file->getClientOriginalName();
$con = file_get_contents($main_file->getRealPath());
$files = Crypt::encrypt($con);
dd($files);
$file = Input::file('file')->getClientOriginalName();
$contents = File::get($main_file);
dd($contents);
Now to authenticate with this saved encrypted data, what is the possible way to save the encrypted 3322 characters in database, i am really in a stuck. can anyone help me...the main task is to login with file contents..thanks...
Sounds like you're trying to implement some kind of shared private key authentication. It's not clear why you want to do that (more on that later), but it sounds like a bad idea right from the start because you are immediately confronted with a difficult problem: how do you get the private key from the client to the server in a secure way?
A better way to do it would be a private/public key system, similar to the sort of thing SSH does when you set up passwordless login. Basically (very basically - I'm not an expert) the idea is that the client generates a private/public key pair and then sends the public key to the server. On authentication, the private key is used to encrypt a message. This encrypted message is sent to the server, where the public key is used to decrypt it. If the correct message was received, then the client is authenticated.
Rather than having some sort of shared certificate, I'd recommend following this model. That way you don't have to share sensitive information (the client's private key) with the server.
Ultimately, you need to think about why you want to do this.
You think this will be more convenient for clients? Well, for SSH, it certainly is more convenient to log in this way, because SSH has a mechanism for automatically encrypting and passing messages in a secure way. For HTTP? Not so much. The user is going to need to generate a file then use an upload form just to log in. Passwords are much quicker and easier.
You think it will be more secure? The way you've described it (a shared private key) will probably be less secure because you somehow have to get the private key from the client to the server without it being compromised - remember, if the private key is compromised, anyone can impersonate the client. The way SSH does it is more secure because the private key never leaves the client.
Ultimately, I think you can probably get what you're looking for with a) strictly enforced password complexity rules and b) HTTPS.
If security on your site is so important that you cannot rely on HTTPS and complex passwords, then you should probably be looking at a more comprehensive solution that will encrypt all traffic between the client and the server, such as a VPN (virtual private network).
I am stuck to retrieve the Key_block generated after the SSL handshake. I implemented a simple Client.cpp/Server.cpp program that is working well for exchanging encrypted data.
I would like to retrieve the key_block because I want to re-use it and perform my own encryption in another communication, but without having another handshake again.
I tried :
ssl->s3->tmp.key_block
but it retrieves an empty string (?!) and of course
ssl->s3->tmp.key_block_length
retrieves 0 value.
I call these methods just after SSL_accept(ssl) succeeds.
Once I've been able to catch this key_block, I'll need to find the encryption function used by SSL_write(...)
Hope you hear me, because the openSSL doc seems encrypted to my eyes.. =)
XY problem. You don't need this. Just open another SSL connection to the same target and it should re-use the same SSL session and therefore the same session master secret. Maybe even the same session key, but what do you care, as long as it's secure? You seem to be just trying to avoid a second full SSL handshake, but you can do that by suitable configuration at the client.
I'm working on a slightly esoteric project where we need to implement some basic authentication in a small/slow embedded micro (no OS). The device serves a couple of web-pages through its serial port which then get squirted over the IP network by a bit of hardware we have no control over.
The server code, such as it is (think nweb on a starvation diet), takes in HTTP GET/POST requests and spits out pages & changes its settings accordingly.
We need some way of authenticating a user login/session so that we don't allow people to see data or change settings they shouldn't.
The device is not intended to be directly exposed to the internet or be 100% impregnable to serious hacking (network security / separation is the customer's issue*), the security requirement is more about keeping the lower ranks from touching the blinkenlights ;)
Due to the lack of space/processing power (assume we have ~2k of code space and not many MHz) we can't implement things like SSL, but it would be nice to go at least one better than the bog standard HTTP access control.
We can handle GET, POST and set/read cookie data. One thing our micro does have is a decent crypto-standard hardware random number generator, should that be of any help at all.
= Really the customers should be hanging the device on its own network, physically disconnected or at least firewalled to death, from anything else. But hey, if it works for Boeing...
If you only want to protect against access:
Any time there is a GET request, look for a cookie of the password.
If the cookie isn't set, send back a HTML login form that POSTs password to server.
If the server gets the POST data with the right password send back a "logged in ok" page that sets the COOKIE to the password. Then anyone who login (with the right password obviously) will have the cookie set in all future GET requets. Anyone who has never logged in will always see the login page. You can 'hide' it by setting two cookie values: A random number, and the XOR of the random and the password. This way clients won't be able to figure out what the values in the cookies are. If you go futher and XOR it with say the client IP, clients won't be able to copy the cookies to other computers. The server will always be able to un-do everything and figure out the password/ip from the random number and the other cookie values.
If you want to have simple encryption you could use XMLHTTPREQUESTS in javascript. Have the server encrypt data with a simple puesdo random number generator (or a simply XOR obsfuncitation or whatever) and have the client do the same thing backwards in javascript. You can have the server encrypt every page except say index.html, and in index.html you can have it so it XMLHTTPREQUESTS the other pages in javascript and decrypts them, then puts the contents into a div using innerHTML or whatever.