SHA-1 is a hashing algorithm, such as MD5 that accept any input up to 2^64 bits and returns a "hash" of 160-bits (which is 40 characters in hexadecimal because it takes 4 bits for one character). This function allows you to make a digital fingerprint of a file, or a word, etc, ecause it's supposed to give you an unique condensate (hash) of your input.
SHA-1 was created based on SHA-0, which was designed by the NSA and published in 1993. Security flaws were found on this algorithm, which was based on the equally flawed MD4, and so it was improved to give the SHA-1 algorithm in 1995 (again by the NSA).
Though SHA-1 is more secure than MD5, for which collisions were found very early, it's now considered as insecure after collisions were found by Antoine Joux and other reasearchers. They discovered a way to produce collisions after "only" 2^69 operations, that was improved into 2^63 since then. This is considered a flaw as a normal collision attack based on birthday attack initially took 2^80 operations to be done, which was considered as secure enough. The SHA-1, as the other hashing function, is supposed to give you an unique hash (as stated before collisions were found, and anyway 160-bits gives a very large but finite number of possible output), which means that if you change only a letter in the input, all the hash will be different. For instance if we hash the word "Password" with a capital P it produces this hash :
No matter the input length, the result will be a 40 hexadecimal characters hash. Which is why SHA1 is still widely used as digital signature. It tends to be less and less used with time, it was replaced by Sha2 (224, 256, 384 and 512 bits), and more recently by Sha-3.
As we saw before, a hash is the result of a cryptographic function (here SHA-1) that takes any input and produces a 40-hexa hash. That also means that we lose information in the process. Since you could produce a hash with an entire book (again the input can be up to 2^64 bits which is huge), you understand pretty easily how there would be no way to reproduce the plain-text or file with only the hash as an input. It's called a one way hash function, which means as the name states, that you can only go from plaintext to hash. Now how do we decrypt SHA1 hashes if you cannot use the hash as input for a decryption function ? Well first of all, we do not "decrypt" a hash. We use this word because it's a convenient way to name what we do, which is more of a hash lookup.
The only way to decrypt a hash is to compare it with a database containing couples of plaintext:hash (so rainbow tables or hash tables, which are not the same things). This is what we have here as we store dozens of billions passwords in a flat database. These passwords are stored in a way that improves both diskspace and lookup speed. So when you enter a hash in the search bar, we look for hashes that starts with the same sequence (call it a partial match), then we check for those hash if the associated passwords match your particular hash. If so we return it to you.
Our service is totally free. We also store every unfound hash and attempt to bruteforce them every few weeks. So if your hash wasn't found, you could come back after some time to check if we cracked it. If we finally didn't manage to crack your hash(es), you could then use your own computer to bruteforce them using hashcat if your GPU is fast enough. Mixed with wordlist and rules this can be a very powerful tool. You could also use paying cracking services such as hashes.com or onlinehascrack.com for instance.
As we said before, SHA-1 isn't secure anymore since collisions were found. It's still widely used though for file signature, or even as password storage by webmasters that aren't up to date or that actually doesn't care too much about security. Now if you use SHA-1 to store your user's passwords, and doesn't want to switch to a better hashing function, you can actually implement salting without user friction.
Salting is adding a randomly generated string (ideally 128-bits long or longer) to the user's password. This salt will make online database such as this one
useless as we would have to recalculate every hash to add the salt. To implement this on an existing database, you can add your salt to the SHA-1 hash instead
of the plain password. So you would only have to recalculate every hash with a salt, salt that would be added to the user's database entry. For instance
if you have a salt like this : 4,;aW-(4+#1q:=c7 and you user's password SHA-1 is this one : 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
then you would hash this :
It would take several centuries to crack this using plain bruteforce. Now when a user want to login on your site, you just have to SHA-1 his password, then add the salt to the hash and re-hash it all, then check with the hash you created in the database. You can also implement a site-wide pepper, which is a sequence that is shared by all passwords that you add to the user's password or hash.
If you can though, it would be better to use slow hashing function as Bcrypt or Blowfish which were designed in a way that makes bruteforce useless.