Why do sites provide MD5 checksums on file downloads? For example, XAMPP at https://www.apachefriends.org/download.html.
My understanding is that it is to show authenticity and credibility, but if that were the case couldn't the site calculate and provide a checksum of whatever file (malicious or not) that they are delivering to you?
It's true that if the site that is hosting the file is compromised, these hashes would provide little value - but it is common for there to be a third-party host (to save bandwidth, or provide backup sources). So, if I provide a hash for the file on my site, but I use a third-party host, you could double-check the value to ensure that the file is not being modified by the file host.
In your case, the installer is actually being provided by sourceforge.net (at least when I tried it), which, ironically, has been getting a lot of flack recently for modifying files just like we described. So, double checking the hash is probably a good idea!
Another benefit to sites provide these is because a MitM attack could modify files (like executables) in transit. This means that even though you trust the site and the host, there may be some intermediate vulnerability that is infecting the file. Sure, a sufficiently advanced attack could manipulate both, but if that's the case, they probably don't need to go to that trouble.
So, the hash isn't a way of saying that the file is safe. It's a way for you to see if the host providing the file is providing the same file. If you don't trust the web page, then the hash is of no value (security-wise).
You didn't ask this, but one reason for providing both and MD5 and SHA1 hash is that while it may be possible to create a file with an MD5 collision, and in some cases SHA-1 can be broken too, I haven't heard of any cases where you can generate a malicious file that is a collision for both. It's trivial for the site to calculate multiple hashes, but computationally unfeasible for an attacker to create a malicious file that "double" collides with the real file (as far as I know!).
Hash functions such as MD5 validate the integrity of a file. Authenticity verification is provided when you compare the hash value with one received from an authenticated source, which in this example is the XAMPP website. A hash function can be run against any file or data stream, so yes, a site can calculate and provide a checksum of any file, malicious or not.
Related
I read the wiki-page of "Cryptographic Hash Function" today.
And I got to know that, md5 has been applied in verification of file.
There is something I can't figure out, here it is.
Suppose I want to download a file(.exe, .iso, whatever) from a website.
1.Does the server first transfer the md5 code of the file to me?
If so, how do I store the md5 code? store the code in a file?
2.When the downloading is done, how do I start the verification process?
Am I supposed to do the verification manually or the downloader (be it a chrome explorer download tool) does the verification automatically?
3.If the file I'm downloading is intercepted by some Hacker on the internet, then will the Hacker know what the file is ?
And how to prevent the interception?
thank you.
Further to previous answers, the purpose of the MD5 published on download websites has nothing to do with crackers (man-in-the-middle attacks). It's just to make sure you downloaded it correctly. If some bits were corrupted for whatever reason, the software mightn't run. Security is much more complicated to set up than one little hash, but luckily your browser knows how to deal with that: whenever you connect over TLS (SSL, https) it will set up a secure connection. Just by watching how much data is sent, even though he can't see what the data is, an attacker may be able to guess which file you're downloading.
MD5 checking is entirely manual. You download it or copy and paste it yourself.
Every operating system should come with an md5 program; Windows is probably the only one that doesn't. Google for one if you have the misfortune of needing to.
With md5 alone, he certainly can see what the file is. The only way to prevent the interception is to use encryption, which most sites provide using https URLs.
Edit: What is an MD5? It's just the value of a little calculation done with all the parts of the file. You send the file, and do the calculation yourself using the md5 program, and check that you get the same value as is listed on the website. The calculation is clever, and if one or more bits of the file are corrupted, the calculated MD5 value will change, so you know that the download didn't work and you need to download again.
The file and the MD5 hash of the file are transferred separately. You are expected to calculate the MD5 hash of the file for yourself and compare it with the downloaded version. If they match then the files are the same. Think of MD5 as a more elaborate version of a checksum.
If you want to prevent interception then you need to encrypt the file, which is a separate question. If you want to ensure the the file is truly the original and you haven't been fooled by a false copy, with false MD5 hash, then look at HMAC.
There are probably browser plugins that will let you do hash-verification automatically. I haven't researched any previously.
A website will usually provide a hash, in hex format, next to the download link.
Once you have downloaded the file, you 'feed' it to a tool which will calculate the hash of the file. Almost all programming languages will have the ability to do this, and there are many googable tools to do so.
If the hash that you generated yourself matches the one shown on the website you know that the file is not corrupt / is the correct one.
MD5 is the most common hash function used to do hash verification. It is not advised to use for security purposes anymore, but it is perfectly fine to verify a file's contents are correct (in 'casual' circumstances).
Digital signing is also used to ensure a file is correct and was generated by a known person/authority/site.
I recently signed up for a cloud hosting service that allows for one click application setup and updates using GIT. I created a WordPress application and pulled the code, only to realize that they used my account password as the database password (i.e. the password I used when registering for the service).
This was a bit unnerving. If I ever had my laptop stolen, or accessed without my knowing someone could easily destroy all the apps that I host using the service. When I asked the host about it, they claimed to use AES encryption (as opposed to password salts) and that the connection to the repositories is protected.
Is this a bad design? Is it reasonable never to store passwords in a GIT repo and to enforce salting on passwords? My only other experience is with Heroku where passwords are not included in config files (and my password has never shown up as plain text). Thanks!
I'd like to say that they shouldn't store passwords in a format that can be decrypted at all, instead prefering hashed and salted.
However, the problem here is that they need to access the GIT repository on your behalf. Which means the password has to be decrypted by their servers at the time of use in order to pass it on to the other system.
In reality due to these requirements there is no real way to completely protect it. Sure it's encrypted, however, that decryption key is available to someone that hacks the machine.
It really doesn't matter if you use different passwords or the same one. If their site is hacked then the passwords can be exposed.
So, the real question isn't how are they encrypting it (doesn't really matter). The real question is how are they monitoring the site in general to ensure it hasn't been hacked. This boils down to whether they are using an IDS/IPS (Intrusion Detection/Protection System). If they aren't, then move on to a different provider that is using one.
Ahh, the old "Don't worry, we use AES!" defense. If I understand your statement correctly, it would seem that they're storing their users' passwords unhashed in a single file then encrypting that file with AES. If so, then yes that's bad design generally. The standard method is of course storing hashed and salted passwords in an unencrypted file.
Storing passwords in an encrypted file suffers from a number of problems:
1) What is the password to the encrypted file? For "turtles-all-the-way-down" reasons, you can't encrypt that password. It can be stolen / guessed.
2) You have the standard password problem on the encrypted file. Do you make it low entropy and memorize it? Do you make it high entropy and store it on a disk somewhere. Both have obvious issues, and remember that this key is a single point of failure for the whole system.
3) Anytime their system needs to verify a password, it has to decrypt the file. So in all likelihood, both the file's encryption key and all the file's passwords will be loaded into memory on the server in plaintext.
As for the "They use my one password for both my overall account and my database access" problem, that's more debatable I think. On one hand you might want to limit how much access any one password gets you. But on the other, having to make a different password for every little thing leads to bad password creation and password reuse.
I was wondering whether a login system that implies that have to upload a certain file and then the server verifies that this is equal to the one stored in the server would be useful.
I was thinking that to its advantage, it would have that the "password" (the file) could be quite large (without you having to remember it).
Also it would mean that you would have to require a login name.
On the other hand one disadvantage would be that you would have to "carry around" the file everyone in able to login.
I dont want to turn this into a philosophical rather a programming one.
I'm trying to see the usability, safety/vulnerabilities etc
Is this or something similar done?
I am definitely not a security expert, but here are some thoughts.
This sounds somewhat similar to public key encryption. If you look into how that works, I think you will get a sense of the same sort of issues. For example, see http://en.wikipedia.org/wiki/Public-key_encryption
In addition to the challenge of users having to carry the file around with them, another issue is how to keep that file secure. What if somebody's computer or thumb drive is stolen? A common approach with public-key encryption is to encrypt the private key itself, and require a password to use it. Unless you provide the file in a form which requires this, you are counting on your users to protect the file. Even if you are willing to count on them, there is the question of how to give them the tools they need so they can protect the file.
Note that just like passwords, these files would be vulnerable if a user used one to login from a public machine (which might have all sorts of spyware on it). It's an open question whether a file-based system might slip under the spyware since they might not be looking for it. However, that is not so different from security by obscurity.
Also you would want to make sure that you hashed or encrypted the files on your system. Otherwise, you would be doing the equivalent of storing passwords in plain text which would open the possibility of someone hacking your system, and then being able to log in as any user.
what you are saying can match to a physical factor of two factor (password + physical factor) authentication system. But it can not be a replacement of password, because password is something you know & file is something you have. Now if you turn the password into file you are losing one factor and somehow you have to compensate that :-) Maybe using something you are.
A C/C++ based cgi web application will be creating a temporary text file on the server as long as the user is logged in. The text file will be deleted when the user logs off. I want to encrypt this text file and also the content of the file. The file will contain information like username and password.
What is the best way to do this?
EDIT: I see libraries being suggested. My problem is I cannot use anything but Standard C++ library.
Use a well known library such as openssl and follow well known examples and stay away from platform specific solutions.
I think you might be going about this the wrong way. If security, real security, is the goal then you're not going to want to store the password even in its encrypted form (because it can be decrypted if the key is stolen, as other people have said).
What you should do is store a hash of the password (with an appropriate salt). This means that no one (not even the site admins) can determine a user's password. They can merely accept a password and see if it's the right one or not by hashing the input with the same salt (you can't reverse a hash).
Also, this sort of situation lends itself nicely to databases, are you using one?
Google password hashing with salts and you can read about it from real security experts (I am not one).
An encryption standard that currently is considered as "safe" is AES (also called Rijndael). You can find a C++ implementation at Codeproject and in many other places.
Please note, that when using AES or any other symmetric encryption standard, you must store the encryption/decryption key inside your application. If anyone discovers the key, he can decrypt all files that you encrypted with this key.
If your application will run under Windows, you also might use DPAPI to store the encrypted information.
Revised answer.
You want code to encrypt and decrypt a file that can be used with your C++ code.
It would be absolutely incorrect to write your own code (like this one).
But, you say that you cannot use standard libraries.
Standard (and, maybe opensource) libraries are probably the most correct approach to implementing encryption in your applications. If you choose to not do that, it leaves you with only two options,
Implement your own version of a standard encryption algorithm (and risk weakness by any errors you make)
Use a 'system' call from your application and run a standard encryption (like bcrypt) that maybe (hopefully) available on your system.
I would still stick to picking up a standard library or integrating such an opensource code into my application. Please explain what prevents you from doing that.
Old: for some reason, i thought a PHP code was required... my error.
This article gives a PHP encryption symmetric program example using crypt to store password in a text file.
Possibly related Stackoverflow questions
discussion on the best C/C++ encryption library.
discussion on plain text storage of password.
So I have a web application that integrates with several other APIs and services which require authentication. My question is, is it safe to store my authentication credentials in plain text in my source code?
What can I do to store these credentials securely?
I think this is a common problem, so I'd like to see a solution which secures credentials in the answers.
In response to comment: I frequently use PHP, Java, and RoR
I'd like to see some more votes for an answer on this question.
Here's what we do with our passwords.
$db['hostname'] = 'somehost.com'
$db['port'] = 1234;
$config = array();
include '/etc/webapp/db/config.php';
$db['username'] = $config['db']['username'];
$db['password'] = $config['db']['password'];
No one but webserver user has access to /etc/webapp/db/config.php, this way you are protecting the username and password from developers.
The only reason to NOT store the PW in the code is simply because of the configuration issue (i.e. need to change the password and don't want to rebuild/compile the application).
But is the source a "safe" place for "security sensitive" content (like passwords, keys, algorithms). Of course it is.
Obviously security sensitive information needs to be properly secured, but that's a basic truth regardless of the file used. Whether it's a config file, a registry setting, or a .java file or .class file.
From an architecture point of view, it's a bad idea for the reason mentioned above, just like you shouldn't "hard code" any "external" dependencies in your code if you can avoid it.
But sensitive data is sensitive data. Embedding a PW in to a source code file makes that file more sensitive than other source code files, and if that's your practice, I'd consider all source code as sensitive as the password.
It is not to be recommended.
An encrypted web.config would be a more suitable place (but note can't be used with a web farm)
It appears the answer is the following:
Don't put credentials in source code but...
Put credentials in a configuration file
Sanitize log files
Set proper permissions/ownership on configs
Probably more depending on platform...
No, it is not.
Plus, you might want to change your password one day, and probably having yo change the source code may not be the best option.
No. Sometimes it is unavoidable. Better approach is to have an architecture set up where the service will implicitly trust your running code based on another trust. (Such as trusting the machine the code is running on, or trusting the application server that is running the software)
If neither of these are available, it would be perfectly acceptable to write your own trust mechanism, though I would keep it completely separate from the application code. Also, would recommend researching ways to keep passwords out of the hands of predators, even when stored on local machine - remembering that you can't protect anything if someone has control of the physical machine it is on.
If you control the Web server, and maintain it for security updates, then in the source (preferably in a configuration module) or in a configuration file that the source uses is probably best.
If you do not control the Web server (say, you are on a shared or even dedicated server provided by a hosting company), then encryption won't help you very much; if the application can decrypt the credentials on a given host, than the host can be used to decrypt the credentials without your intervention (think root or Administrator looking at the source code, and adapting the decryption routine so that it can be used to read the configuration). This is even more of a possibility if you are using unobfuscated managed code (e.g., JVM or .NET) or a Web scripting language that resides in plaintext on the server (like PHP).
As is usually the case, there is a tradeoff between security and accessibility. I'd think about what threats are the ones you are trying to guard against and come up with a means to protect against the situations that you need. If you're working with data that needs to be secure, you should probably be redacting the database fairly regularly and moving data offline to a firewalled and well-protected database server as soon as it becomes stale on the site. This would include data like social security numbers, billing information, etc., which can be referenced. This would also mean that you'd ideally want to control the servers on your own network which provide billing services or secure data storage.
I prefer to keep them in a separate config file, located somewhere outside the web server's document root.
While this doesn't protect against an attacker subverting my code in such a way that it can be coerced into telling them the password, it does still have an advantage over putting the passwords directly into the code (or any other web-accessible file) in that it eliminates concern over a web server misconfiguration (or bug/exploit) allowing an attacker to download the password-containing file directly.
One approach is to encrypt The passwords before placing the password in config.web
I'm writing this for web service app that receives password, not client:
If you save hashed passsword in source code someone who views the source code won't be able to help himself with that hash.
Your program would receive plain password and hash it and compare both hashes.
That's why we save hashed passwords into databases, not plain text. Because they can't be reversed if someone for example steals db or views it for malicious purposes he won't get all users passwords, only the hashes which are pretty useless to him.
Hashing is 1 way process: it produces same value from same source but you can't compute source value out of hash.
Storing on client: when user enters pass u save it to db/file in plaintext, maybe obfuscate a little but not much u can do to prevent someone who gets a hold of that computer to get that password.
Nobody seems to have mentioned hashing yet - with a strong hash algorithm (ie SHA-2 and not MD5), it should be much safer.