Our vendor needs some access to our test server, and thus we send them email with username/password (i think it's unencrypted).
What is the most unintrusive way to bump up the security level?
Thanks
Call them on the telephone.
Send the two parts with separate communication channels.
Use a combination of any two of the following.
Voice phone call.
Fax.
Snail Mail.
Encrypted Email.
Separate channels makes it very hard to reconstruct the credentials.
Depending a the level of security you're going for. It's usually inversely proportional to convenience. So here are some in order of least secure.
Zip file with password protection (winzip)
If you're both using Windows send them the information in locknote.exe. It's very easy and the security in the code is very tight. ( http://www.steganos.com/us/products/for-free/locknote/overview/ )
Get their public key and have them SCP to your server to pick up the password file.
Setup encrypted email and either send them your key or setup your public key on a public key server.
These are just some thoughts off the top of my head.
Call them, especially if you already know their voice. A more traditional solution (that requires some setup) is GPG.
Related
We are building an android application and one of its features is to book a cab service provider's cab (say an Uber).
We have an application specific user ID. Let us call it AUID. To book the cab, the application would Post a request to server and send AUID along with other relevant information (like lat, long etc). How do I make sure at the server end that the request is indeed coming from the correct user and it is safe to book the cab? In the current form, if a third party gets to know the AUID of another person, the third party can book a cab on behalf of that person.
One of the solutions I thought of was using asymmetric encryption. The application would hold the public key and the server would contain the private key. Instead of sending the user ID to the server, we'll instead send an encrypted key where the key would be AUID + timestamp encrypted using the public key. We'll then decrypt the message using private key at server end to obtain the AUID. If the timestamp at server does not lie within a certain interval of the timstamp sent by the client, we reject the request.
Is this a safe enough approach? Is there any other practice widely followed for such scenarios?
What you propose is sensible: encrypt the AUID on the client app and verify on the server. As comments suggest, SSL is vital.
The problem is that if how to encrypt the AUID is in your app, it can be figured out by anyone dedicated enough.
You can drastically reduce the risks of fake requests by issuing a separate encryption key for each user. This means that if someone cracks your code, they can still only spoof from one account. However, once an attacker had decompiled your app, they could theoretically start new accounts, get a valid encryption key and spoof requests.
What you need for 100% reliability is some form of authentication which is not stored in the client app - like a password or TouchID on iOS or fingerprint api on Android M. So when a user orders a cab, they need to enter some piece of information which you also encode with the AUID and check on the server. That secret information is not stored in your app, so no-one can fake requests.
Requiring a password from a user is pretty inconvenient. Fingerprint scanning is much easier and probably acceptable. You could also use a trust system - if the user has ordered cabs before and everything was OK, they can order without special authentication. Using Trust together with individual encryption keys is pretty effective because anyone trying to spoof requests would need to do a successful order before being able to spoof - which is probably too much hassle for them.
I've coded the mobile api using Node.js, Redis & MongoDB. However right now I am looking for a concrete way to provide security in our system. The question I have inspired by the infamous principle of Auguste Kerckhoff;
"It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience"
After inspecting this principle I figure out that there is no safe way to secure data after a sniffer capturing the entire data package. Of course there are alternate ways like using an API key, using encryption algorithms like MD5 & MD6,Triple DES,SHA1 etc. However this also won't work if the entire data package is captured. And there is security precaution standarts like HTTPS, SSL certificates. However again if someone with talent captures the data package it can act just like a verified user in our system.
How would it be possible to apply a security method such that even though the entire data package is captured, the system would be able to distinguish the request coming from an outer source not from our verified user.
PS: I thought that applying a custom encryption algorithm with timestamp in order to prevent this problem could be a bit chaotic.
According to Kerckhoffs's principle "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." So the way cryptosystem, works is that the key is the only thing that can be used to decipher the system. If the key is fallen to the enemy then its all over.
In practice when you communicate over the internet or try to
authenticate your email account with the password. Your password is
never sent to, nor stored on the server in plain text. If you do then,
its not secure. The best security practice is not to store the
password at all (not even encrypted), but to store the salted hash of
the encrypted password.
That is one hash for one user. It is one way, you cannot get back user info, just test if it is in the database or not. Now even if the enemy takes control of the database, it cannot access your username/passwords.
Now coming to the point, it does not matter what you transmit in the communication channel, because the communication channel is the enemy!!! It is available to other users, anyone can sniff it. It is like enemies scanning each other on the radio.
The hash that has been sent over the channel can be sniffed and be used for authentication. True, but server can differentiate between spoofed attempt and the actual attempt, using HTTPS connection. Server tracks the HTTPS sessions and would ask to revalidate if something like this happens. HTTPS blocks use of sniffed data / MITM attacks. Even if sniffer gets hash (temporary ticket), he cannot do anything malicious, username and password cannot be cracked.
Thanks to Kerckhoff, our passwords are safe.
How to implement it on node.js ?? look for passport.js package. It implements the current standard OpenAuth.
I have been asked to develop a highly secure B2B File Transfer system between three companies.
VPN is not an option and they prefer to use common ports like 80,443, etc, so no extra firewall configuration shall be done.
i found solutions like oftp2 and as2 to be sufficient enough. although, i have some questions before i can decide:
is not https file transfer secure enough. so i can use asp.net/C# to do the task.
what about existing tools like SFTP, rsync and other *nix tools.
what about using SOAP?
my main concern is to avoid any possible clear data exposing to the outer world.
all ideas are appreciated.
thanks in advance.
if you use a block cipher like AES to encrypt the data and send the result using RSA encryption that will do the job. For the RSA you encrypt using their "Public key" which you get them to send to you out of band (Courier service) then they decrypt with their private key. This is totally secure providing both companies keep their private key secret. You have a key pair for each of the 3 companies. The extra AES layer is if you are really paranoid and really really want to make sure even if someone got the private keys they still can't read the data. Also you should sign all messages: send a hash of the rest of the message encrypted (AES) with your private key then the recipient can decrypt with your public key, and hash the data themselves and if their hash is not the same as your one that was attached after it was decrypted then it was not from you. This prevents man in the middle, domain in the middle etc interceptions. This would only allow someone to interfere if they got both the public and private key and the AES password... at that point the estimated crack time is well over 2 billion years with 2048 bit RSA so I think you're safe.
Technically you can always do a scp/rsync over ssh, if port 22 is among the white-listed port. If not, you can run a ssh daemon on 80/443 etc.
To answer your question, yes https/SFTP are secure enough, so is rsync if done over a encrypted channel (refer http://troy.jdmz.net/rsync/index.html)
Another thing you can explore is stunnel ( http://www.stunnel.org/ )
I can think of more than one ways to go about it. Totally depends on your servers' OS and other restrictions you may have.
The main issue with SSL is certificate validation. By default all certificates matching the target domain which are signed by any of a plethora of CAs is considered valid. If you are paranoid, you should check the certificate used on the connection directly against the a certificate stored in your configuration.
Using a DHE handshake to achieve perfect forward privacy would also be nice, but the built in SSL API in .net doesn't expose a way to enforce that. So you might or might not get DHE depending on the version of windows and .net.
Another good choice is tunneling something over SSH. For example SCP is an existing file copying utility that does this.
OK, you don't want to expose the file contents, with files to be exchanged between three parties, to anyone else.
There are two things to consider:
1) Protect the transport. Here, the files are sent over an encrypted link. So, you're basically putting the normal bits into a tunnel that is encrypted to protect anyone from snooping over the link. This is usually done using SFTP for company-to-company communications and keys are exchanged and authenticated out-of-band before any transfers occur.
2) Protect the files. Here, each file is encrypted independently and then transported to the destination. You encrypt the files of the file before they leave your network and then they are decrypted once they arrive at their destination. This is usually done using PGP for company-to-company communications and the PGP keys are exchanged and authenticated out-of-band before any transfers occur.
If you protect the transport, you're just sending the data through a protected pipe, linking the companies. Once the file is received, it's not encrypted (it's only encrypted through the pipe). If you protect the file, you are block-encrypting files themselves, so it's more of a process to encrypt and decrypt the files; only the actual process/system that has the PGP keys at the receiving end can decrypt the file.
So, what do you want to do? That's a risk decision. If you're only concerned about someone intercepting the file contents that is not company A or B (or C), you need to protect the transport (SFTP, et al). If you're concerned about protecting each file independently and making sure that only specific processes at the receiving end can decrypt the file, you want to protect the files. If the data is very sensitive, and under high risk, you may want to do both.
Some very good points have been made in security issues of developing your own file transfer programs. There are software security, network security, and user authentication security issues involved here. Understanding all the various encryption algorithms and security rules take years to master and is a time consuming endeavor for the development team to just keep up with all of the intricate changes in digital security standards and laws.
Another option is that there are several very good and affordable managed file transfer (MFTP) solutions that have already developed and addressed all of these security issues. They also have mastered the workflow of file transfer management to make this process much much easier on the IT staff. One of these MFTP solutions that I've used for the past few years is Linoma Software's GoAnywhere product. It has saved our team months of time and headache, allowing us to focus on our core business.
I hope this helps...
I've built a client-server system, where clients sign in to communicate securely with other clients through the server.
Here are the properties of my system:
-Client-server communication is SSL encrypted
-Client login details are stored as hashes securely with their salt on a database stored locally on the server
-On login, every client sends a session public key to be stored on the server, which other clients use to encrypt a symmetric key. The symmetric key is used for later message encryption to prevent server eavesdropping
-On chat initiation, fingerprint user authentication is used to ensure user is who he/she pretends to be. It is usually done through a phone call reading out the fingerprint, which is a SHA256 hash of both public keys split in two and XORed for convenience.
-MAC is sent along with every message
What would you suggest to improve this? What possible attacks could my server suffer?
Thanks
It seems like you could still suffer from a Trojan client application, but what you really need to do is take a step back from the various security technologies. What does all this security protect? Who would like to break it? What would they do if they could break it? Answers to those questions will help you identify how the system might be attacked, and propose useful countermeasures.
It looks like you are looking at this problem haphazardly - build a threat model of your design; and mitigations will come to you! Start here: http://www.microsoft.com/security/sdl/getstarted/threatmodeling.aspx
Is it better (more convenient or secure) to provide users with a lost username or password via direct message on Twitter rather than via email?
You don't supply lost passwords at all (mostly because you can't, because if you're doing it right you don't store passwords in plain text anyway).
You facilitate a reset-feature that allows the user to, with the help of for example a secret question or simply an activation link via email, change their password.
I really don't want sites throwing my username and password over Twitter.
No thank you!
It is as secure as sending it over email. If you generate a new password and then send it to the user via dm only the user can read it. And yes the user can access twitter in an unsecure way over an not encrypted connection. But you can't assure that somebody uses an encrypted connection to access his mail either.
In fact it could be more secure because you know that only twitter admins can intercept the message and no admin reading the mails from his users
Security aside, there's also the significant flaw that you can't send password reset information, password reminders, or anything else to your user via direct message if he's not following you on twitter. Unless your site is itself a twitter client, then the odds are pretty good that a substantial fraction of your potential users won't be particularly interested in following you and are likely to resent being told that they must follow you (or at least follow/change password/unfollow) if they want to use your site.
Update: I forgot to mention... If you want to tie your user authentication functionality to twitter, then why not just use Twitter OAuth instead of maintaining your own password store at all? It works quite well (barring the fail whale), is very quick and easy for the users, and doesn't place any requirements on who they follow or don't follow.
Start by reading this post: What is the best “forgot my password” method?
This will get you started in the right direction.
I want my password sent by UPS, FedEx, or USPS when I forget them.
Punish the user.
Bad user.
Enough people have pointed out that you shouldn't be storing passwords in plain text anyway, so I won't repeat that.
But if you're sending a one-time-use password-reset link as a Twitter DM, then you have to take into account that the user might receive that message on their mobile phone.
Then you'll have to make sure whatever that link points to is set up to display correctly on mobile phone web browsers.
Then you'll wish you just stuck with email.
Secure your passwords and don't send anything by email or twitter. Lookup MD5 and other algorithm to do this.
Wikipedia says:
In cryptography, MD5 (Message-Digest
algorithm 5) is a widely used
cryptographic hash function with a
128-bit hash value. As an Internet
standard (RFC 1321), MD5 has been
employed in a wide variety of security
applications, and is also commonly
used to check the integrity of files.
I hate it when I see a website storing my password without encryption... and if the website started sending me my password via twitter I'd break something.
Instead of sending passwords verbatim over any insecure channel, send a nonce instead. Such as: a one-time URL the user clicks, verifies personal info, then is forced to choose a new password.
This way, if the message is intercepted, no damage can be done without also hacking the personal questions.