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
I'm making a web application and would like to have a secure area where you can only sign in with your finger print. My original idea was to just use a usb barcode reader and you scan that, and it outputs the ID into a text box, but that's not very secure. So I want to use a USB fingerprint reader to maybe generate a hash for each person and store that in a text box instead. Which then will check that against a database with everyone's hash value. Does anyone know if there is a fingerprint reader out there that can do this, or of a way I can easily integrate a reader into a website?
EDIT:
The Idea for this website is that it's like a login system (Sort of like how you can clock in and out if you get paid hourly) The idea is that no one can sign someone else in and out. IF you just use a password, than someone can just tell their friend the password who can type it in. That's why I thought of a fingerprint, or something similar... I'm open to other suggestions
Also, I'm using PHP
EDIT 2: The Basic idea, is I have to come up with a way to Prove someone was there by checking in. I don't want to use passwords, because then someone can just tell someone else their password to type in. Any other suggestions? It doesn't have to be fingerprints.
Biometrics are a very bad way to do authentication for many reasons:
They're essentially just a password that you can never change. (At least not without some serious pain!) With traditional password schemes, if your password gets stolen or guessed, you can at least change it. But if someone steals your fingerprint, now what are you going to do?
Biometrics are not secret. Every time you touch something, you're leaving your password laying around. Every time your picture gets taken your facial image / retinal image gets copied. Passwords have to remain secret to be useful.
Like Borealid said, Biometrics are never scanned exactly the same twice. So when you do matching, there has to be some kind of fudge factor in allowing input. This:
Just makes it easier for attackers to copy your data and replay it, since they don't have to get an exact match. An attacker only has to get close to get accepted.
It forces the authentication server to store the your biometric info in plaintext. You can't hash biometric data like you can passwords, since then you'd have to match exactly with the hashed value.
So don't do it!
You can't do what you want, exactly.
Fingerprints never exactly match. Even if you scan your own right index finger twice in a row, the scans won't be the same. So "hashing the fingerprint" won't work - two hashes of the same finger would be indistinguishable from two hashes of two different fingers (with a good, cryptographically strong hash).
Fingerprint readers work by storing some key onboard, and letting that key out if and only if the fingerprint given is close enough to what they expect. The fingerprint itself is not used to get direct access to anything outside the reader.
Sending the fingerprint as seen by the reader over the network is not acceptable - people are nervous about giving their prints to police. You think they'll be OK giving them to you?
Also not acceptable is having the reader say "finger 2 is OK". This could be easily spoofed.
Instead, have your user use X.509 (SSL) client certificates to access your site. They may, if they wish, control access to their private key via the fingerprint reader.
EDIT: updating this answer. There is, now in the year 2014, a standard from the FIDO Alliance called "UAF" which allows sites to use fingerprint authentication in a way that works across different sites. Rumor has it Paypal is going to begin using it soon.
Biometry for remote authentication is never secure. You can't know if a real finger with that fingerprint is in a reader, or if the user only sends you an image. So a fingerprint just becomes a password the user can never change, which is the same for every service you login to, and which is left on every object the user touches.
Biometry can only work for local authentication where you trust the reader to be not hacked(i.e. you have physical control over the reader) and the reader can distinguish a real finger/eye/... from a fake one. Which most can't.
It is possible to create a one way hash of a finger print. You first have to extract a number of observables just like you might do for a fuzzy match. But since you need an exact match for a hash you need to throw error codes at the values you extracted which then can correct the minor differences on each measurement. It's not easy to code and it doesn't fix the fundamental problems listed above, but it should be possible.
So you want to use a local authentication mechanism to authenticate a remote resource? There are many issues here to suggest this would not be a smart choice. E.g., how does the web app know the hash belongs to the original user and not someone who has a duplicate?
What I would suggest instead is to go the route of banks from several years ago when they had smartcard readers sent to credit card customers. Use the fingerprint scanner to store a local copy of the user's login name, requiring a second form of authentication such as a password.
This is so bogus. Why can't you encrypt a fingerprint? Your master is stored encrypted, you send an encrypted one to the server. The server software un-encrypts both and does the comparison. Simple. Your 'expert' solutions are bogus.
why not use face match software for authentication.
http://www.oculislabs.com/products/privateeye
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 8 years ago.
Improve this question
I have been reading/googling for the last week on best approach to this issue/application.
I have an app that is bascially a database front end, currently it stores data locally, all works happily (available in the app store).
What i want to do next is store this data on a server.
(Before this i had no experience in server at all so everything from this point on from my own research and asumptions, if something is incorrect please point it out to me).
I decided that a RESTful webservice design would be best for what i wanted.
Basically intention is iPad/Android will be able to talk to web service, web service sits on top of a MySQL database, web service will receive strings, vidoes, photos.
My current situation is i can get the webservice to talk to the MySQL database, i can send simple requests from iPad for data (strings) and to post data (strings), (Still need to figure out best way of handling photos and videos, but thats a different issue).
My Question: What is the best way of making this web service Login/Secure.
The data is sensitive so has to be secure. Currently the user can't access the app without a username & password, but obeviously i need to take precations in the web service also.
I have done loads and loads of googling research and even topics on here i seem to be constantly seeing comments along the lines of "This method is out of date" etc.
It seems to be there are two fundamental approaches,
1) Basically having a GUID which is configered on inital start up <-I think
2) On every request for data also transfering password/username.
Any help guidance would be greatfully recieved.
Thanks
P.S. Sorry about the essay
It is possible to encrypt and sign the data exchanged between the server and the client. For that you can generate your own trusted certificate for free. You'll have to look for the methods based on the technologies you are using. This will protect you against man in the middle attacks as an intruder can't read or alter the data.
Any passwords you use in the code should be encrypted to protect against reverse engineering (at least for amateurs)
Use key based encryption algoritms
Capture all the exceptions, an error should never be transmitted to the client as it's a door to your system.
Protect your wsdl file (if you have any) against public viewing.
Validate your forms, the user shouldn't be able to inject special characters like "<",">","'","=","-"...
This is what I can think of for now.
You can use the following approaches to make your API secure.
oAuth implementation to send and receieve data with authentication headers.
SSL certicificates to make sure the communication between your server and client is encrypted. You can easily buy a private certificate for as low as $15/month.
Hash database fields such as password. (Make sure NOT to use MD5 as it is not secured. Use SHA1 or SHA2 instead).
Don't store user passwords in mobile applications, store some sort of hashed auth key, instead.
I have a php/js site where the information is encoded and put into the database. The encryption key for the information is randomly generated, then given back to the users after they send a post through a form. The encryption key is not stored in my database at all. A seperate, randomly generated, ID is formed and stored in the database, used to lookup the item itself before deciphering it.
My question is, is it possible at all to look through the logs and find information that would reveal the key? I am trying to make it impossible to read any of the SQL data without either being the person who has the code (who can do whatever he wants with it), or by a brute force attack (unavoidable if someone gets my SQL database)?
Just to re-iterate my steps:
User sends information through POST
php file generates random ID and access key. The data is encrypted with the access key then put in the php database with the ID as the PRIMARY KEY.
php file echos just the random ID and the access key.
website uses jQuery to create a link from the key and mysite.com?i=cYFogD3Se8RkLSE1CA [9 digit A-Ba-b09 = ID][9 digit A-Ba-b09 = key]
Is there any possibility if someone had access to my server that can read the information? I want it to be information for me to read the messages myself. The information has to be decodable, it can't be a one way encoding.
I like your system of the URL containing the decryption key, so that not even you, without having data available only on the user's computer, will be able to access.
I still see a few gotchas in this.
URLs are often saved in web server logs. If you're logging to disk, and they get the disk, then they get the keys.
If the attacker has access to your database, he may have enough access to your system to secretly install software that logs the URLs. He could even do something as prosaic as turn logging back on.
The person visiting your site will have the URL bookmarked at least (otherwise it is useless to him) and it will likely appear in his browser history. Normally, bookmarks and history are not considered secure data. Thus, an attacker to a user's computer (either by sitting down directly or if the computer is compromised by malware) can access the data as well. If the payload is desirable enough, someone could create a virus or malware that specifically mines for your static authentication token, and could achieve a reasonable hit rate. The URLs could be available to browser plugins, even, or other applications acting under a seemingly reasonable guise of "import your bookmarks now".
So it seems to me that the best security is then for the client to not just have the bookmark (which, while it is information, it is not kept in anyone's head so can be considered "something he has"), but also for him to have to present "something he knows", too. So encrypt with his password, too, and don't save the password. When he presents the URL, ask for a password, and then decrypt with both (serially or in combination) and the data is secure.
Finally, I know that Google's two-factor authentication can be used by third parties (for example, I use it with Dropbox). This creates another "something you have" by requiring the person accessing the resource to have his cell phone, or nothing. Yes, there is recourse if you lose your cell phone, but it usually involves another phone number, or a special Google-supplied one-time long password that has been printed out and stashed in one's wallet.
Let's start with some basic definitions:
Code Protecting data by translating it to another language, usually a private language. English translated to Spanish is encoded but its not very secure since many people understand Spanish.
Cipher Protecting data by scrambling it up using a key. A letter substitution cipher first documented by Julius Caesar is an example of this. Modern techniques involve mathematical manipulation of binary data using prime numbers. The best techniques use asymmetric keys; the key that is used to encipher the data cannot decipher it, a different key is needed. This allows the public key to be published and is the basis of SSL browser communication.
Encryption Protecting data by encoding and/or enciphering it.
All of these terms are often used interchangeably but they are different and the differences are sometimes important. What you are trying to do is to protect the data by a cipher.
If the data is "in clear" then if it is intercepted it is lost. If it is enciphered, then both the data and the key need to be intercepted. If it is enciphered and encoded, then the data, the key and the code need to be intercepted.
Where is your data vulnerable?
The most vulnerable place for any data is when it is in clear the personal possession of somebody, on a storage device (USB, CD, piece of paper) or inside their head since that person is vulnerable to inducement or coercion. This is the foundation of Wikileaks - people who are trusted with in confidence information are induced to betray that confidence - the ethics of this I leave to your individual consciences.
When it is in transit between the client and the server and vice versa. Except for data of national security importance the SSL method of encryption should be adequate.
When it is in memory in your program. The source code of your program is the best place to store your keys, however, they themselves need to be stored encrypted with a password that you enter each time your program runs (best), that is entered when you compile and publish or that is embedded in your code (worst). Unless you have a very good reason one key should be adequate; not one per user. You should also keep in-memory data encrypted except when you actually need it and you should use any in-memory in-clear data structures immediately and destroy them as soon as you are finished with them. The key has to be stored somewhere or else the data is irrecoverable. But consider, who has access to the source code (including backups and superseded versions) and how can you check for backdoors or trojans?
When it is in transit between your program's machine and the data store. If you only send encrypted data between the program and the data store and DO NOT store the key in the data store this should be OK.
When it is stored in the data store. Ditto.
Do not overlook physical security, quite often the easiest way to steal data is to walk up to the server and copy the hard drive. Many companies (and sadly defence/security forces) spend millions on on-line data security and then put their data in a room with no lock. They also have access protocols that a 10 year old child could circumvent.
You now have lovely encrypted data - how are you going to stop your program from serving it up in the clear to anyone who asks for it?
This brings us to identification, validation and authorisation. More definitions:
Identification A claim made by a person that they are so-and-so. This is usually handled in a computer program by a user name. In physical security applications it is by a person presenting themselves and saying "I am so-and-so"; this can explicitly be by a verbal statement or by presenting an identity document like a passport or implicitly by a guard you know recognising you.
Validation This is the proof that a person is who they say they are. In a computer this is the role of the password; more accurately, this proves that they know the person they say they are's password which is the big, massive, huge and insurmountable problem in the whole thing. In physical security it is by comparing physical metrics (appearance, height etc) as documented in a trusted document (like a passport) against the claim; you need to have protocols in place to ensure that you can trust the document. Incidentally, this is the main cause of problems with face recognition technology to identify bad guys – it uses a validation technique to try and identify someone. “This guy looks like Bad Guy #1”; guess what? So do a lot of people in a population of 7 billion.
Authorisation Once a person has been identified and validated they are then given authorisation to do certain things and go to certain places. They may be given a temporary identification document for this; think of a visitor id badge or a cookie. Depending on where they go they may be required to reidentify and revalidate themselves; think of a bank’s website; you identify and validate yourself to see your bank accounts and you do it again to make transfers or payments.
By and large, this is the weakest part of any computer security system; it is hard for me to steal you data, it is far easier for me to steal your identity and have the data given to me.
In your case, this is probably not your concern, providing that you do the normal thing of allowing the user to set, change and retrieve their password in the normal commercial manner, you have probably done all you can.
Remember, data security is a trade off between security on the one hand and trust and usability on the other. Make things too hard (like high complexity passwords for low value data) and you compromise the whole system (because people are people and they write them down).
Like everything in computers – users are a problem!
Why are you protecting this data, and what are you willing to spend to do so?
This is a classic risk management question. In effect, you need to consider the adverse consequences of losing this data, the risk of this happening with your present level of safeguards and if the reduction in risk that additional safeguards will cost is worth it.
Losing the data can mean any or all of:
Having it made public
Having if fall into the wrong person’s hands
Having it destroyed maliciously or accidently. (Backup, people!)
Having it changed. If you know it has been changed this is equivalent to losing it; if you don’t this can be much, much worse since you may be acting on false data.
This type of thinking is what leads to the classification of data in defence and government into Top Secret, Secret, Restricted and Unrestricted (Australian classifications). The human element intervenes again here; due to the nature of bureaucracy there is no incentive to give a document a low classification and plenty of disincentive; so documents are routinely over-classified. This means that because many documents with a Restricted classification need to be distributed to people who don’t have the appropriate clearance simply to make the damn thing work, this is what happens.
You can think of this as a hierarchy as well; my personal way of thinking about it is:
Defence of the Realm Compromise will have serious adverse consequences for the strategic survival of my country/corporation/family whatever level you are thinking about.
Life and Death Compromise will put someone’s life or health in danger.
Financial Compromise will allow someone to have money/car/boat/space shuttle stolen.
Commercial Compromise will cause loss of future financial gain.
Humiliating Compromise will cause embarrassment. Of course, if you are a politician this is probably No 1.
Personal These are details that you would rather not have released but aren’t particularly earth shaking. I would put my personal medical history in here but, the impact of contravening privacy laws may push it up to Humiliating (if people find out) or Financial (if you get sued or prosecuted).
Private This is stuff that is nobody else’s business but doesn’t actually hurt you if they find out.
Public Print it in the paper for all anyone cares.
Irrespective of the level, you don’t want any of this data lost or changed but if it is, you need to know that this has happened. For the Nazi’s, having their Enigma cipher broken was bad; not knowing it had happened was catastrophic.
In the comments below, I have been asked to describe best practice. This is impossible without knowing the risk of the data (and risk tolerance of the organisation). Spending too much on data security is as bad as spending too little.
First and most importantly, you need a really good, watertight legal disclaimer.
Second, don’t store the user’s data at all.
Instead when the user submits the data (using SSL), generate a hash of the SessionID and your system’s datetime. Store this hash in your table along with the datetime and get the record ID. Encrypt the user’s data with this hash and generate a URL with the record ID and the data within it and send this back to the user (again using SSL). Security of this URL is now the user’s problem and you no longer have any record of what they sent (make sure it is not logged).
Routinely, delete stale (4h,24h?) records from the database.
When a retrieval request comes in (using SSL) lookup the hash, if it’s not there tell the user the URL is stale. If it is, decrypt the data they sent and send it back (using SSL) and delete the record from your database.
Lets have a little think
Use SSL - Data is encrypted
Use username/password for authorisation
IF someboby breaks that - you do have a problem with security
Spend the effort on fixing that. Disaster recover is a waste of effort in this case. Just get the base cases correct.
I really don't think there is a way for this to be done safely but maybe there is a more outside the box way to approach the task.
I am working on a project management site. Some of these projects would be Websites so the client wants to be able to display the ftp, database and hosting information. This would require me to display username and passwords unencrypted on the web. I obviously see the huge risk in this because if the site gets cracked it has information that could destroy other sites as well.
One way I can think to approach this is encrypting the passwords and then creating an application that they would keep locally on there machine to decrypt that password. This is really the only "safe" way I can think of.
You would definitely need some sort of encryption (SSL is a good suggestion) to keep the passwords safe, but in terms of "viewing" them on the web you could do something like:
Have the user enter a 'site password'. You could also use a captcha to prevent bots from getting at your passwords. This will allow them to view their own password for a short period of time, say 10 seconds. Their password would be displayed in an input box, or some sort of box, that would be readonly. They should not be able to copy/paste passwords.
Having username and password information up on the screen is definitely a security risk, but this all depends on how security sensitive your information is going to be.
Another solution could be that if they need to view their password, they are required to change it the next time they log in. This will allow them to view their current password, but will negate the security risk of having that password stolen since they would be resetting it almost immediately.
All of this depends on how sensitive the information is of course.
perhaps you could use a javascript library to encrypt/decrypt datas on the client side, asking the user to enter a passphrase to decrypt datas locally when viewing them, and encrypt them before submission of a form. This way only crypted datas will transit over the network and wihtout the passphrase you only access crypted datas.
Start with SSL for the secure transit.
Encrypt the information before storing it.
Read some articles on how hackers get into these sites, plug the holes before you learn a difficult lesson.
NEVER display a password, you don't need to. Use a login link, where you can include tokens and checks that ensure the user clicking on it has the appropriate permission level.
Example: Employee gets fired. He is upset captures the screen with all of the passwords on display. Not a great situation for your company or the former client.
Using my method, the user could capture the screen, copy the links, it would have no effect, as his token would be revoked and the link wouldn't work. Your client site is safer this way.
The simplest and safest way to do this would be to use SSL.
If you can't go that route than you'll need to come up with your own way of encrypting the information during transit. This is difficult. You'd need something like a Diffie-Hellman key exchange (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), a large number of primes for the client-side to choose from, and then javascript to encrypt and decrypt the information using the exchanged key. You could improve on this by having pre-cached the javascript, downloading it from a third party, and (preferably) doing a checksum to ensure that you JS hasn't been modified.
However, since the encryption code and primes are sent plain-text through the internet, they could be modified en route allowing an attacker to manipulate where POSTs will be sent and how information will be encrypted.
In short, if you're not using SSL, you have not way to guarantee that information is transferred securely.
One thing you might do is tap into PGP. If the user uploads their public key, you'd be able to return messages to them safely. This is because the PGP software is independent of the browser/internet.
I'm working on a small webapp that generates exercise program printouts. A user (ie personal trainer) can create an exercise program, then enter the email address of one of their clients. A link to the exercise program then gets sent to the client, like so...
http://www.myurl.com/generate.php?hash=abiglonghash...
The hash is a sha512 string.
I don't want people to be able to easily discover other people's exercise programs. At the same time I would really prefer to avoid prompting people for additonal password info, etc, when they click on that link. I would like a client to click on the link in their email, and immediately get their program, no fuss.
I'm wondering what thoughts are as to the security of the above, without additional authentication? I know it's not Fort Knox, but it seems about as safe to me as a typical "Forgot your password" system. Any thoughts, suggestions as to how this could be improved, without getting into full-blown user authentication?
Thanks in advance,
A "forgot password" system typically does a few things:
Requires you to "know" something once you get to the page (like your mother's maiden name, your high school, etc)
Sends you your new password in an email. Even if you get to the 'forgot password' URL of another user, the new password is sent to that user's email address on file. This means you would need access to their inbox, as well as their "secret question"
For your purposes, a SHA512 string should be secure enough. Using a SHA512 is similar to using a UUID, in theory. It is long enough to be statistically improbable that someone could guess someone else's hash. The odds of it happening are astronomically high.
Of course, there are always easier ways than guessing to get access to someone else's hash. Things like the user's browser history, intercepting their net traffic, looking over their shoulder, etc. Only SSL combined with a protective login system would protect against those things.
Security always brings up questions like these. Obviously the only way to keep all the people you want out is to keep everyone out! But that is not going to work.
If all you are interested in doing is shallowly hiding a user's workout program from another, then what you are doing is not a problem at all and there are no security issues.
If someone guesses (or investigates and finds) a link to another workout program, then there is nothing you can do to stop it with your system. If that is a concern, then you are going to have to come up with another method to know who you are letting in. If you don't care about people actively trying to get at others' workout programs and only trying to stop this from happening incidentally, then you have no problem.
Technically it's exactly as safe as a login/password pair, 32 chars each, i.e. very. Even brute forcing for random records is not an option. With a billion users and billion brute force attempts per second it would take well over 10^100 times the age of the universe before you found a working hash.
In practice there are other consideration, such as caching proxies, browser history and so forth. I would recommend against doing this with important data, but it's really in how you present and explain it to users.
I think this is not a bad idea as long as you don't allow those "magic tokens" to continue to work forever. You should store the tokens in a database and keep track of whether they've been used. Once a client uses the magic token to reach the system, they really should create a "normal" account with a username and password, like every other site on the internet. After that use, the token should be marked as "used" and further uses of it should be disallowed.
I have a piece of shareware that I wrote that I'd like to distribute on the internet. I have a serial number type thing set up but there is still a ton of key sharing :(. I'd like to add a system where once the user enters the serial, it is checked with my server to make sure that it is valid. Simplicity is key.
-Client sends MD5 of serial number to web page using php type thing "www.mywebsite.com?key=3434343"
-Php script takes MD5 and checks it against simple database. If MD5 key exists in database, it increments a counter associated with that key, and generates a webpage that displays a 1. If no entry in the database, the script generates a webpage that displays 0.
-Client reads webpage and checks for 0 or 1 and acts accordingly.
I will manually enter in valid keys (md5'd) in the database and monitor active keys for too many activations. I don't know anything about php so I don't know if this will work. Does this seem good enough? Are there blatant security holes? I will be using a shared host. Is there a better way? Thanks
There are actually several blatant security holes in your scheme.
The first is that users can redirect their local internet traffic to a site that pretends to be you, but always displays a "1".
The second is that each key would only be good for X "activations", but if the message is lost in transit, too bad - the counter is still incremented. You need some way to validate that everything is OK; viewing the page is not enough.
The third is that hacking the program to think it got a "1" from your site would be the easiest thing in the world.
Don't implement your own copy protection. It will just annoy legitimate users, while not even slowing down real pirates. Either use a sophisticated commercial system, or (better yet!) try to strike at whatever motive is leading users to steal your program. This might be that your price is too high, or perhaps they don't feel you respect them. People do things for a reason.
You're lacking a vital understanding of the key... the key is in form of MD5 which will contain both alpha and numeric characters, consider this as an example:
3c102d6b53a7a8723e694f1417c2abfe
How are you going to generate the key? On what basis you generate the key from?
I also, see in this is the passing of the key to the website using the parameter like this:
www.mywebsite.com?key=3434343
It will take a while for the hacker to find a key...what with the advent of processor speed and key generation.... it will be cracked in no time, further more, you will be exposing your script.... do not underestimate what hackers/crackers can do to break the scripts... which is something you did not mention in your posting, no security defences of any kind!
Also, there's no mention of using security certificates to authenticate and not to scare off the end user or even worse, an antivirus scanner may flag the site as suspicious thus the end user is locked out of the application.....
BOTTOM LINE: Do not try security schemes like this as they are false economy, either way, it would be equivalent of a moth attracted to a flame, when an application "is protected", hackers/crackers will attempt to bypass it regardless of what you think..and you would be kidding yourself into thinking and deluding yourself that you're a brilliant programmer and that your dreamt-up-scheme is foolproof - DON'T...Stay away from these kind of schemes....
I would echo the points that have been raised in the comments about why you should consider not doing this, or at least not doing it yourself. But if you really want to (and/or for educational purposes), for a system like this I'd go for asymmetric encryption.
Basically, the idea is that you generate a public/private key pair, embed the public key in your application, and keep the private key on your server. In order to get registered, a copy of your application would send the serial number to your server. The PHP script on the server would check its database for that serial number, decide whether the registration is valid, and if it is, the server sends back the serial number encrypted with its private key. Your program can then use the public key to decrypt the message received, compare the decrypted version against the serial number, and if it matches, it can activate itself. Of course, this won't foil a (semi-)determined hacker, but it does eliminate the easiest way to get around the scheme you gave in your question, namely redirecting the request to a site which always returns a 1.
If you're worried about serial numbers traveling over the internet unencrypted, you could use the public key to encrypt the serial number before the program sends it to the server. And when the server responds, instead of sending back the encrypted serial number, it would send back (1) a random number generated on the server and (2) an encrypted hash of the random number and the serial number. Or use HTTPS, which does something similar. But if you're trying to protect against someone who has the means and motivation to intercept communications between your program and the server, you'll need more than just this simple scheme because that person almost certainly has more sophisticated tools at his/her disposal. In that case you would need a reputable commercial DRM system to have the best chance of protecting your program. And at that point, I'd ask yourself whether it's really worth it.