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 last month.
Improve this question
I'm working on a small web project with a friend. It involves a lot of MySQL queries, so I've created a ConnectToDatabase() function that connects to the server and selects our database.
It looks something like this:
function ConnectToDatabase()
{
mysql_connect("db.myawesomehost.com", "Bob", "correcthorsebatterystaple");
mysql_query("USE BobDB;");
}
It feels really bad to hard-code our credentials like this. I can't think of any other way to handle it, though. Putting it in a constant doesn't really solve anything, and hiding it away in some text file just seems ridiculous.
Should I even care? How is this handled in large projects with tons of people?
Factor it out into a separate config file. For one, it'll let you at the very least set some variable like "DEBUG_MODE" that will switch out your production credentials for your test environment ones. You can optionally not keep the separate file under version control if you like, or keep one with dummy credentials in your code repository so that users have to supply their own credentials instead of having access to global ones.
You should not hard code any credentials. Best thing is to read from a configuration file and cache them. Even in that case you better not put credentials in clear text - we need to encrypt the credentials in configuration files. At WSO2 all the credentials we read from configuration files are kept encrypted and use an approach called Secure Valut [a generic approach] to read those encrypted credentials and provide in clear text to the required application...
Thanks...
Typical rails configuration has usernames and passwords stored in a file.
It seems reasonable to split them out so that you can share code without sharing machine specific information. This is useful for multiple developers who have more than one user for their dev DB.
Reading from a file shouldn't be that much of a burden, particularly a file of some format: xml, json, yaml, ...
As the other answers suggest, most large projects hard code the username and password somewhere in the project, usually in a configuration file. I have never seen any that do it another way, however in the specific case that non-logged-in users do not need database access, it is possible encrypt the DB credentials and use everyone's password as a passphrase to decrypt them. Another drawback is if the user forgets their password, they won't be able to recover it without admin intervention and all existing users would need their passwords to be reset.
Related
how can I make a login form that will remember the user so that he does not have to log in next time.
Some more information would be nice but if you want to use a database for this then you would have to create a entry for the user information last entered.
And then on reopening the programm you would check if there are any entrys and if yes load it.
But I think that writing the login information to a file on you pc would be a lot easier. So you run the steps from above just writing to a file instead of a database.
I am not sure how you would make this secure because you can't really encrypt the password because you would need a password or key of some type and that password or key would be easy to find in the source code especially in python. It would be harder to find in other compiler based programming languages but also somewhere. And if you would use a database you would have a password for that but that would also lay on the hardrive if not encrypted otherwise but there we are where we started.
So as mentioned above a database would be quite useless for a task like this because it doesn't improve anything and is a hassle for beginners to setup.
So I'm currently working as part of a project for a degree course. We have a real client who is having a website developed for them. There are connections to Databases within this site, which are stored in the "appsettings.json" file of the project. This is all local stuff at the moment but will be moving to a live server in the next couple of days.
I am wondering if this JSON file needs to encrypted or abstracted from so that the connection strings, which include the obvious things, IP's, Passwords, Users, can't be accessed by someone attempting to break into the site.
If it does, what is the best practice to go about this?
Cheers
This may not be the quick answer you are probably hoping for, but a better way for your app to receive its database credentials (and indeed all secrets) through environment variables.
It sounds like you are a student. Congrats! Those are fun times. As you gain experience, you'll run into many problems such as this that are best handled by sticking to the 12-factor app guidelines. It would be well worth your time to review those.
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 7 years ago.
Improve this question
i've always wanted to make some of our companies products open-source..but we have a lot of things in our source code that would make us vulnurable. How is this handled in most open source projects? For example, we use some custom web services to do actions to our database (Add accounts, delete accounts, ect). The source code would have to contain the key (password) we use to use the web service. If someone wanted, they could grab the source, get the key to use our web service, and wreck havoc on our database.
Are these just projects that should not be open source? Or is it common to just put the sensitive stuff in a file or something and not include that part? (Although doing this, would make the source kinda useless for the public since it would lose it's functionality).
Any links or resources on open-source projects and how this kinda stuff should be handled would be nice.
Thanks
Passwords and senstitive data are best not included the source file. If you look at the design of open-source software like PHPMyAdmin, a config file is provided to add in those information, and are usually stored in the root folder of the webhost (or anywhere outside www folder).
So the idea is that if your website use some info to link to a service, you should hide them away in a file as well and ask your user to provide the password and to create their own account.
Would it not be possible to put your sensible data into a configuration file? This will also allow other users to easily add their own sensitive information etc.
You should not include the sensitive data into the public, so one option could be to make a public API for the services, and then the users would need to create an account to get an API key for the data.
I don't think this should stop you from Open Source the products, but I think you need to rethink the way the data is handelend trough a public API.
If you're hardcoding a database password in your code, you're doing it wrong. As others have pointed out, you should store that in a separate and protected configuration file.
If you distribute your code, be it the source or just a binary, that password is out there and can be recovered by anyone that cares to do so. Hardcoded passwords in binaries are often a trivial matter for a hacker to recover.
Though program codes are open-source, your sensitive data is not. Never "provide" your data to others.
Normally, one-way hashing verification can already be used as basic encryption.
If extra security is needed, use an extra measure, like public & private keys & pre-shared passwords.
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 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!