I use the Linkchecker module on my website but the database stores my urls as a urlhash. I'm not familiar with this kind of security, so is there anyway I can revert these strings back to the original url?
Hashing is a one-way process, designed to create signatures or fingerprints that are easily comparable by a machine.
Reverting hashes to their original strings is almost impossible (depending on the hashing algorithm) and involves reverse engineering and number crunching.
So, to answer your question in short: no this is not possible.
see a similar discussion on md5
Related
I do understand Tangle has a graph based data structure i.e. forming a direct acyclic graph. It is not a merkle tree like a typical blockchain. But I could not figure out this relation makes it quantum proof or not. Is no-mining, and peer verification enough to make a distributed ledger quantum proof?
I asked a very similar thing here https://bitcoin.stackexchange.com/questions/55202/iota-quantum-resistance
The way the ledger is organized: linked-list (as in blockchain) or DAG (Tangle) has no impact for sure. There is still some sort of PoW (when you submit a new transaction) but that is also irrelevant.
Basically with a quantum computer cryptographic one-way hash functions (like SHA-2, SHA-3, BLAKE2) are still ok with a few caveats, the same goes for block ciphers (like AES). Traditional public key cryptography (RSA, DSA, Diffie-Hellman and the eliptic versions) are however NOT secure anymore. So you can't have signatures (which is a quite necessary thing for cryptocurrencies). There are some complicated workaround constructions but the simplest is one based on hash functions (Lamport OTS). More references are in my question. Note that I still don't know how exactly IOTA does this. Basically I got stuck at reading about their Curl hash function.
Because Spring deprecated the old interface
org.springframework.security.crypto.password.PasswordEncoder;
I looked for alternatives that work with
org.springframework.security.authentication.encoding.PasswordEncoder;
My search points me to: https://stackoverflow.com/a/18678325
I tested bcrypt and I was interested how it works.
The explanation at https://stackoverflow.com/a/6833165 points me to one question.
If $2a$10$ZaDBCZaI59IMdKuBiRdubuMa2h/itIYIwqLHpS1q245ISD90xsjkW contains all information about the type of encoding and the salt and so on, and this is stored in my database why is it save?
If someone has this "hash" he can easily decrypt it with brute force.
Within my previous project I used a SHA encode with a system wide secret salt. In this scenario the hash stole from the database can't easily be decrypted.
So why is bcrypt preferred to a SHA with system wide salt?
2 points:
Bcrypt is designed to resist brute force attacks by having a configurable complexity that makes the process arbitrarily slow. Refer to wikipedia for more details
Using the same hash for all passwords, as your existing system does, may be vulnerable to differential attacks, since each password in the database is known to contain a shared component.
I’ve a web application (asp.net mvc) and I need to encrypt some data that will be stored in the database.
Since I’m using BCrypt for the user password, I was thinking on using it as well to encrypt other data… what do you think? Is BCrypt just for passwords or can I use it as well for other data? Or maybe there is a best way to do it?
Thanks in advance!
BCrypt does not encrypt anything. It is a HASHING algorithm that uses Blowfish internally, but does not actually encrypt your data.
The main difference:
Hashing is an algorithm that takes data of variable size and generates a fixed-size representation of that data. The original data, unless stored elsewhere, is lost AND cannot be retrieved.
Encrypting is an algorithm that takes data of variable size and generates a similarly-sized chunk of data. The original data, unless stored elsewhere (thereby voiding the purpose of encryption), is lost. It CAN, however, be retrieved. The Encryption process uses a separate piece of data called a Key. Provided the associated decryption algorithm is used, the same key will decrypt the data and the original information can be retrieved.
So:
Before anyone can answer your question, you must first understand what you are asking. Do you, in fact, need to store encrypted information, or rather is it hashed information? If you merely need to store sensitive information, but never need to return the original value back to the user, then continue using BCrypt, as it will hash your data (thereby making it unreadable, but still comparable). If, on the other hand, you want to store sensitive information that you one day may need to supply to someone (for instance, a credit card number), then look into sql encryption algorithms.
As you explore the world of security, you will quickly find that it is very painful, but very important. For instance: SLaks brings up a good point. If you encrypt your data, somewhere, somehow, you need to store your key. But if that key is found, then someone can steal all of your data! You must find a way to properly encrypt your data while hiding the key from the public. There are several ways of doing this; google around a bit before you commit to one, as it may not be as secure as you think.
Microsoft has some good recommendations: http://technet.microsoft.com/en-us/library/ms345262.aspx
You did not specify what flavor of sql you are using, so a flavor-specific answer cannot be supplied.
For my current application I use a very simple scheme to register new users. When a new user registers an email is sent with a key. To check wether this key is correct a kind of checksum is computed (3-7-11 digit check) which is added as the last 2 digits of the key. There is no check on any further validity of the key. The application does not check whether the key got invalidated.
It is a simple scheme and someone took the time to crack it by deassembling the code. I want to use another scheme for my new application but I am not sure what is the best way to do this.
Is there a Delphi library I could use?
Is it advisable to use some user supplied info in the key, like his name?
Is there a best practice way of registering users?
Anything else I have forgotten?
Some registration schemes require an application to check each time at a webserver whether the key is still valid. I'd rather not go that far because this requires a lot of effort on the server side.
Any suggestion or link for a robust way to register new users is very welcome.
A better registration scheme is based on asymmetric cryptography (usually RSA algorithm). The idea is that only you can generate a valid key, while everybody can check that a key is valid (asymmetric cryptography allows this trick). So when you see your program with a valid key on torrents you just cancel support for a customer who was given this key.
There are Delphi and non-Delphi libraries (i.e Protexis) available to protect your software - remember that almost anything that works with C can work with Delphi as well. But a sound copy protection scheme may be hard to achieve. A simple key may not work, usually it used together a machine fingerprint to allow it to be used on given system only.
A good key generator algorithm should generate keys that are not easily predictable, yet can be checked if valid. There are different ones around, there is not a "generic" one, depends on your needs, some may also include what features to activate or expiry informations. Some keys can be strings, other can be whole license files (as those used by Delphi itself). Anyway code can be disassembled to try to guess the algorithm, some techniques to obfuscate it and make it harder to understand can be used.
Also, one simple key check is not enough because it can be easily bypassed patching the executable. If you really need copy protection, you should scatter checks all around the code, maybe encrypting and then decrypting data or code sections using the key - it won't protect you against keygen, anyway and will require more code changes, it's not as simple as calling one function at startup.
The level of protection is up to you. If you need just a simple registration mechanism and you don't mind much about your software being cracked you can use a simple one. If you need a more secure one then there are more sophisticated one.
If your goal is to force people to download a cracked EXE from the Internet instead of a key generator from the Internet, then asymmetric cryptography is your answer.
If your goal is to be able to void serial numbers that have been released to the wild, restrict the number of installations, or force the user to have a real "paid for" serial number, then activation is your answer. Still, if they crack your EXE, they can get around this.
You only have control up to the point that someone cracks your EXE. We have to accept this and move on. We must figure out other ways to reach out to our customers, such as more affordable versions, value added support options, web services, and other ways that convince the user that the price of our software is fair, and there is a benefit in paying.
On my latest release, I use activation, so the serial numbers are randomly generated, though checked for uniqueness, and associated with an email address.
After all of this, the application is just $4.99, but with no individual support. The goal is to make it so affordable that if they want to use it, even just once, it's a good value.
We've been using Oreans' WinLicense for two years and are quite happy with it. They handle key generation (with the user name embedded), trial versions that time-out, hardware keys (where the key you send them is unique for their computer) and VM detection. They also use a variety of other techniques to make it harder for your code to be disassembled, including wrapping code of your choice in an encrypted VM they provide.
You can also disable specific keys if you determine that they are "stolen." Having done this, future updates you supply will no longer run with those keys.
We also have our software "phone home" at certain times to see if their key is stolen.
Any protection scheme can be broken by someone who is determined and skilled enough. But, we've been happy with the degree of security we believe that WinLicense gives us. Their support is also excellent. The library is callable from Delphi.
Hi i would like to know best encryption technique for text file encryption and ecryption.
My Scenario:
I have software having two type of users Administartor and Operators. Our requirement is to encrypt text file when Administrator enter data using GUI and save it. That encrypted file would be input for Operator and they just need to select it and use that file. Here file should be automatically decrypt data for further calculation when Operator select those files.
Please help me which encryption/ decryption technique should i use?
A golden rule when doing crypto is to understand that cryptography as a whole it is very difficult.
There are a multitude of different approaches/algorithms to choose from, and no single algorithm/method can be said to be the best one. It all depends on your needs and possibilities to affect application distribution etc.
An example of a potentially problematic situation is that in your scenario the decryption "key" needs to be distributed with the application(s) and might make it insecure. This is generally referred to as the "Key Distribution" problem.
A good place to start reading about crypto is http://en.wikipedia.org/wiki/Cryptography.
As for ready made stuff for Delphi there are a few good packages available:
DEC v5.2 - http://blog.digivendo.com/2008/11/delphi-encryption-compendium-dec-52-for-d2009-released/
DCPCrypt - http://www.cityinthesky.co.uk/cryptography.html
Torry's pages also has a long list of components:
http://www.torry.net/pages.php?id=519
http://www.torry.net/pages.php?id=312
I strongly recommend you use some of the existing implementations and not start to do your own, since creating a secure working crypto algo is very very difficult.
When moving an encryptet message from place/appliction to another, one of the problems you have to consider is where to store the encryption/decryption keys.
As i se your scenario, it seems like it is build in your applications. If so remember to use al sorts of tricks to hide it: Password strings should be split in several bits and onlys appended in a protected memoryspace, that has to be marked as non-pageable (else password could be seen in the pagefile).
The same rules for the content that is unencrypted (the text-file). It's best that it never is saved (even temporaly) unencrypted to disk. If it is saved, the overwrite the date with garbage after use, before deleting it.
Another approch (specialy if you already use compression components), is that the (text) file, can be compressed using a password.
Truthfully, there is no "best" technique. It basically depends on the sensitivity of the data you're trying to protect and the number of people who might access this data. What might be "best" for me might be pure overkill for your project.
In your case, you could use any dual-key encryption method. Or asymmetric key. Basically, the administrator has one key and the operator has the other. The administrator can then encrypt files, but he won't be able to decrypt them again, unless he has an operator key. The operator can decrypt the file and -if need be- encrypt a file that only an administrator can access. (Asymmetrical keys encrypt in both ways.)
There are several solutions that make use of these asymmetrical keys. The one that would be best is the one that you could add to your project in the easiest way while still offering enough protection for your needs.
Building your own asymmetrical key algorithm is possible too, if you're a real Math Wizard. The calculations are complex and involve extremely high prime numbers in most solutions. As K. Sandell said, find a good, existing solution that matches your needs in the best way.