Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an Android application that transmits some user account information as json over ssl to a central server. 3rd parties can send messages to the users if they have the users' username.
The username can never be queried from our server, infact no user data can be queried. The entire system relies on the fact that the user willingly shared there information with the 3rd parties and the 3rd parties can use that information to deliver messages to the users.
The transmitted data is not encrypted by me, since it is already sent over ssl. I feel that I need to encrypt the data stored on my server to keep it safe. What would be the best way to encrypt this data? When I query the user data, must I encrypt the supplied value and compare it to what is stored in the database or must I rather decrypt the database?
Or is it an overkill since only my server application will ever have access to this data?
It's not overkill to encrypt the private data of your users, customers, etc on your filesystems. For one thing that hard drive will eventually end up out of your control --- and it's extremely unlikely that you're going to properly destroy it after it seems to be non-function, even though there's a bunch of private data on it and potentially accessible to someone with a modicum of data recovery expertise and initiative.
I'd suggest PyCrypto.
The real challenge is how you'll managed your keys. One advantage of PK (public key) cryptography is that you can configure your software with the public (encrypting) key in the code and exposed ... that's sufficient for the portions of your application which are storing the data. Then you need to arrange a set of procedures and policies to keep the private key private. That means it can't be in your source code nor your version control system ... some part of your software has to prompt for it and get it (possibly typed in, possibly pushed in from a USB "keyboard emulator" or other password/key vault device).
This has to be done for every restart of your server software (that need to read back this customer data) ... but this can be a long running daemon and thus only need this a few times per year -- or less. You might use something like a modified copy of the ssh-agent to decouple the password management functionality from the rest of your application/server.
(If you wondering where there's value in keeping the private key in memory if it's always in memory when the machine is running --- consider what happens if someone breaks in and steals your computer. In the process they'll almost certainly power it off, thus protecting your data from the eventual re-start. One option, though weaker, is to use a small USB drive for the private key (password/passphrase) storage. This is still vulnerable to the risk of theft, but less of a problem when it comes to your eventual drive disposal. Hard drives are relatively hard and expensive to properly destroy --- but physically destroying a small, cheap USB drive isn't difficult at all).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am in the process of setting up a digital ocean droplet. I have very little experience with networking and sysadmin tasks.
All of the documentation and tutorials about setting up this droplet highly suggests that I set up an SSH connection. Upon googling, I get very broad definitions and videos of what SSH is, but I cannot seem to conceptualize exactly how it works.
I've even followed the directions of the some of the tutorials without any issue, so apparently I've even accomplished doing this before with my other droplets. However, whenever I log into my droplet with PuTTY or WinSCP, I still need to provide a username and password (even if the password is saved, I need to type it in to save it).
Other pieces of information I've obtained:
When stepping through this process, I noticed that linux will STILL ask me to create a passphrase. But, a lot of the reading I did seemed to suggest I would not need to for some reason.
There is a public and private key. I can't seem to understand what each is for, or what's the difference.
I don't do anything to my home computer. Is an SSH connection verifying that I am indeed logging into my server through my home computer? If that is in fact the case, how does this process know I am logging into my server with my home computer if I did not provide any information about my home computer at all? (Everything was done through PuTTY on my server remotely).
According to a lot of what I read, after setting up SSH, you are then supposed to disable root user access. I'm just not seeing why.
I'm just not really understanding what it is that I'm doing when I create private and public keys. I still have to provide my username and a password when logging into my server with WinSCP and PuTTY. Am I doing something wrong? In reference to SSH; what am I doing? Why am I doing this? Am I doing it right despite the fact that I still have to provide a password when logging in?
If possible, take an "explaining this to a 5-year old" approach.
PuTTY is an SSH client, so you've already been logging into your server via SSH without knowing it. Public-private keys are just an alternative way to log in (besides password login). The way it works is that you generate a public/private key pair on your home computer. Then you give your public key to the server, and instead of logging in using your password (which requires you to type it in), you can log in automatically using your private key. Private key login is also considered much more secure than password-based login when it is done right.
There are already a lot of resources for explaining how public-private key encryption works, so here's one I found on Reddit:
Another way of looking at it is the familiar box analogy. Imagine you want to send a briefcase of information to your friend across the US but need it to be locked so that thieves can't see it. Obviously you can't just put your own lock on there and send it because your friend doesn't have your key to that lock.
The box analogy offers a solution. You put your own lock on the bag and send it to your friend. There, your friend also puts HIS own lock and sends it back. You then unlock your own lock with your key, meaning that the only lock left is your friend's lock. Send it back, and they can easily unlock it and take a look at the information. This is foolproof because a thief would need to know both lock's keys to open the briefcase.
Computing uses a similar model but rather than locks and keys it uses one master lock that can be opened with combinations of three keys, one public key and two private ones that you and your friend each know. Also it takes into account the properties of prime numbers and modular arithmetic. When studying CS, I found that this video helps a lot in understanding how the numberized process of locking and unlocking works.
Source:
https://www.reddit.com/r/explainlikeimfive/comments/1kocba/eli5_rsa_algorithm_and_publicprivate_keys/cbr0l24
In addition, if you want to get public-private key login working with PuTTY, here's a tutorial on that (and it's even specific to digitalocean!):
https://www.digitalocean.com/community/tutorials/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
There are lots of ways to create a login form for web apps and most of them are flawed one way or the other:
Passwords are transmitted/saved as clear text
The login dialogs are subject to XSS attacks or SQL injection
Is there an example or tutorial how to create a secure login form?
I agree with Carlos about lack of "perfect" secure system, not only for login, but for any other component. The only thing to do is to minimize risks by following best practices, but always keeping in mind that total safety doesn't exist, so your question is quite difficult to answer, although there are some good examples out there nothing is perfect, security is a very fast evolving topic.
For me the main things to solve are:
-Data transmission: The user is always going to type a password and this has to be sent to your system before it was processed, so there is a high risk of being intercepted if you are using an open channel. To solve this you MUST use transport the data over an encrypted channel (SSL), no other way unless you drop the common password (for example using one-time use tokens, or delegating the authentication to a third party, like Facebook connect or openId). See "How to Make a Secure Login Form with SSL"
-Input Sanitation: To avoid XSS and SQL Injection consider any input that comes from a client as a potentially risk point, therefore you have to perform validation against anything that comes form outside --> doc. Another good practice is never use the inputs directly on queries, use as bind variables in prepared statements or stored procedures.
-Password Storage: Password should always be stored encrypted with a one way hash algorithm, so even in the case of someone accessing your DB, there is no way to recover the original passwords. Also use techniques as Salting, Hashing multiple times, etc... Also be careful to choose an algorithm that is not weak or outdated (like MD5), which can be broken by brute force easily with the increasing CPU power.
-Infrastructure: Have your machines, OS, frameworks, libraries always updated to avoid bugs and 0 day attack. Any system today is enormously complex, and the system is as secure as it weakest component.
-Other Things to Consider: Review your security policy regularly to see if needs to update anything, implement password policies (expiration, reuse, etc...), log access, use monitoring tools for your systems, etc etc etc
And after all that, you can still be sure that if someone has enough time and resources, your system will fall.
Your question, can't be that agnostic, and must be divided in your two main concerns:
Transmitting passwords in the clear.
Xss, Sql injection.
No system will be declared secured per se, but you can try your best to minimize the risks by using proven concepts.
So let's say you have the chance to design your own "secure system", what do you need?
At minimum you will need a basic set of tools:
Client side data encripting: (Javascript here, i think you will find lots of info of how to send your data in data 64 or something like that, remember you are searching for one way or two way encription)
DB Encription: (One way-two way encription, but never save passwords in the clear)
SQl injection: (mysql_real_escape_string() comes to mind).
Every language has some sort of protection built in, it is when building large projects that sometimes we may forget to sanitize some querys
I repeat no system will ever be declared secure, however you can add some other security measures as in:
access_tokens = timed-strings that allow to validate user login.
captcha_after_few_intents = you should add this definitely.
block_account_after_few_trys = pain in the * for users, but definitely worth it.
login_token = store a token unique for that user, and use it in all GET/POST transactions
SSL
From Bank Security:
Automatic gsm devices that generates RANDS and access_tokens valid only for a short time.
mouse keyboard: evitates keyloggers
random_access_question:
check_random_account_country_change = let's say user is from albany and next day he logs in from south america, that should maybe raise a flag to your system.
I'm sure you will find plenty of advice somewhere, but remember you at end will end talking html, and some js, your main defense is on the server side, so be good, or be good at it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If I had let's say a sensitive report in PDF format and wanted to send it to someone, what is the most secure way?
Does a desktop application make it more secure? Since we are basically doing a client to server communication via private IP address? Then add some kind of standard encryption algorithm to the data as you send it over the wire?
What about a web based solution? In web based, you have a third person in the loop. Sure, it would do the same kind of encryption that I would have on a desktop.. but now instead of client->server directly, you have client->server | server<- client... You also have exposure to the broad internet for any intruders to jump in, making yourself more open to man-in-middle attack... One thing the web has going for it is digitial certificates but I think that is more authentication than authorization.. which the desktop problem doesnt have?
Obviously from a usability point of view - a person wants to just goto a web page and download a report he's expecting. But most secure? Is desktop the answer? Or is it just too hard to do from a usability perspective?
OK there seems to be some confusion. I am a software engineer and am facing a problem where business users have some secure documents that they need to distribute - I am just wondering if using the web and SSL/CA is the standard solution to this, or maybe a desktop application could be the answer??
The method that comes to mind as being very easy (as in it has been done a lot and is proven) is just distributing via a web site that is secured with SSL. It's trivial to set up (doesn't matter if you're running Windows, *nix, etc) and is a familiar pattern to the user.
Setting up a thick client is likely more work because you have to do the encryption yourself (not difficult these days, but there is more to know in terms of following best practices). I don't think that you'll gain much (any?) security from having to maintain a significantly larger set of code.
Most secure would be print it, give it to a courier in a locked briefcase, and have the courier hand deliver it. I think that'd be going overboard, though :)
In real world terms, unless you're talking national security (in which case, see courier option above), or Trade Secrets Which Could Doom Your Company (again, see courier option above), having a well encrypted file downloaded from the web is secure enough. Use PGP encryption (or similar), and I recommend the Encrypt and Sign option, make the original website a secure one as well, and you're probably fine.
The other thing about a desktop application is: how is it getting the report? If it's not generating the report locally, it's really doing just as many steps as a web page: app requests report, report generated, server notifies client, client downloads.
A third option, though, is to use something other than the website to download the reports. For instance, you could allow the user to request the report through the web, but provide a secure FTP (SFTP or FTPS) site or AS2 (or AS3) connection for the actual download.
Using a secure file transfer (or managed file transfer) is definitely the best option for securely transferring electronic data. There are smaller, more personal-use solutions out there like Dropbox or Enterprise solutions like BiscomDeliveryServer.com
Print it off, seal it in an envelope, hire some armed guards for protection and hand deliver it to them.
You may think its a silly answer, but unless you can identify what your threat vectors are any answer is pretty meaningless, since there is no guarantee it will address those threats.
Any system is only as secure as it's weakest link. If you sent the document securely and the user downloaded / saved it to their desktop then you'd be no better off than an unsecure system. Even worse they could get the docuemnt and then send it onto loads of people that shouldn't see it, etc. That leads on to a question whether you have an actual requirement that they can only view and not download the document? If not, why go to all this effort?
But if they are able to down load it, then the most secure method may be to send them an email telling them that the document is available. They then connect to a system (web / ftp?) using credentials sent separately to authenticate their access.
I'm surprised no one has mentioned a PK-encryption over email solution. Everyone in the "enterprise" gets a copy of everyone else's public key and their own private key. Lots of tools exist to do the heavy-lifting. Start with PGP and work from there.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Let's say I have designed s very important system, and this system costs thousands dollars. I want to protect my system with a serial number as I know crackers will try to edit the binary code to bypass the serial number.
I have read about using a checksum function and apply it over my binary code and check the value if changed, but again, we are talking about a condition a cracker can avoid by editing the code.
My question is: what's the most used technique to protect important programs?
I have yet to see a "protected" digital product that had not been cracked pretty quickly after its publication (or in some cases, before its publication). Sorry, but it's the reality. You have to get the revenue by making a good product. Most of those who want to use it and can afford, will pay.
There will be a few dickheads, but that's life. You better be kind towards the legit users of your software and not bully them with weird copy protection attempts that don't work anyway.
If your app is working offline, whatever checks you do (check sums, serial code validity, etc), do them often, repeating verification code, in many routines of your software. Obfuscate your code, to make reverse engineering a more difficult task, and, if you have the possibility, implement an online check, part of the core functionality of your app residing on your server, and being serviced only to those installations that you have checked server-side for valid license key. Associate the license key to some form of unique identifier of the hardware the app is running on, and if you check online, have statistics concerning the IPs that make the verification request: if you encounter more IPs trying to verify the same license key, contact the buyer and approve a list of IPs they usually log on from, whilst blacklisting any other until specific request from them, either by mail or by phone.
The most used technique is serial numbers. But your customers will have access to the code, so they will be able to bypass your serial number check, no matter how much work you put into obfuscating it.
However, if you can provide your software as a subscription-based or one-time-payment web application, then people will not be able to do this. Whether this is feasible or not depends on the type of application you're writing.
I would always recommend to build a custom software protection before applying any kind of commercial protector such as a Packer.
In any case just a serial validation and a checksum check are not going to keep crackers away.
I would recommend you to visit my new blog www.anti-reversing.com and take a quick look at the anti-piracy tips & tricks page just to have an idea about what I am talking about.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm currently setting up a commercial SFTP server and I'm just looking for some of your opinions on the set-up I'm currently thinking of implementing, as well as a recommendation as to what commercial Secure FTP server software would be best to suit. Bear in mind that the data i'm responsible for is highly sensitive so any comments/feedback is much appreciated.
Here's the scenario:
1) Before file upload, files are compressed & encrypted using AES 256 with a salt.
2) Files uploaded from the clients' server over SFTP (port 22) to our SFTP server.
3) Files are then downloaded over HTTPS by our other client using one time password verification (strong 10 char alphanumeric password)
The specifics of the implementation I'm thinking of are:
For part (2) above, the connection is opened using host key matching, public key authentication and a user name/password combination. The firewall at both sides is restricted to only allow the static IP of the client server to connect.
For part (3), the other client is supplied with a user name/password on a per user basis (for auditing) to log into their jailed account on the server. the encryption password for the file itself is supplied on a per file basis, so i'm trying to apply two modes of encryption at all times here (except when the files are resting on the server).
Along with dedicated firewalls on both sides, Access control on the SFTP server will be configured to block IP addresses with a certain number of failed attempts over a short time, invalid passwords attempts will lock out users, password policies will be implemented etc.
I like to think that I've covered as much as possible but I'd love to hear what you guys think about this implementation?
For the commercial server side of things, I've narrowed it down to GloalSCAPE SFTP w/ SSH & HTTP module or JSCAPE Secure FTP server - I'll be assessing the suitability of each over the weekend but if any of you have any experience with either i'd love to hear about it also.
Since the data is clearly both important and sensitive from your clients' perspectives, I'd suggest you consult a security professional. Home-grown solutions are typically a combination of over- and underkill, resulting in mechanisms that are both inefficient and insecure. Consider:
The files are pre-encrypted, so the only gain from SFTP/HTTPS is encryption of the session itself (e.g. login), but...
You're using PKI for upload and OTP for download, so there's no risk of exposing passwords, only user IDs -- is that significant to you?
How will you transmit the one-time passwords? Is the transmission secure?
Keep in mind that any lockout scheme should be temporary, otherwise a hacker can disable the entire system by locking each account.
Questions to ask yourself:
What am I protecting?
From whom am I protecting it?
What are the attack vectors?
What are the likelihoods and risks of a breach?
Once you've answered those questions, you'll have a better idea of the implementation.
In general:
Your choice of AES256 + salt is very reasonable.
Multi-factor authentication is probably better than multiple iterations of encryption. It's often thought of as "something you have, plus something you know," such as a certificate and a password, requiring both for access.
As far as available utilities, many off-the-shelf packages are both secure and easy to use. Look into OpenSSH, OpenVPN, and vsftp for starters.
Good luck - please let us know what method you choose!
So what's wrong with OpenSSH that comes with Linux and the BSDs?
Before file upload, files are compressed & encrypted using AES 256 with a salt.
This part rings some alarm bells...have you written some code to do this encryption/compression? How are you doing the key management? You also say your key is password derived, so your use of AES 256 and salt is giving you a false sense of security - your real key space is much less. Also the use of the term 'salt' is inappropriate here, which suggests further weaknesses.
You would be better off to use a well proven implementation (e.g. something like PGP or GPG).
Also, if you use PGP style public key encryption for the file itself (and decent key management), the security of your SFTP server will matter a lot less. Your files could be encrypted at rest.
The argument for the security of the rest of the system is very convoluted (lots of protocols, authentication schemes, and controls) - it would be a lot easier to secure the file robustly, then do best practices for the rest (which will matter a lot less and also be independent controls).