Is there a way to prevent the same person from referring itself? IP address is obviously not enough to prevent these kind of scammers that know how to game a system like these. So in the current technology, how do you prevent it from happening? I can use sending messages but these process is to extensive for user registration. I can also do credit card validation but it is also very extensive for my system.
I need to track unique visits.. How?
Lets look at this the analytical way.
You need to either know whether the user is already in the system at least one time.
So you need a way of recognizing a user.
There are a lot of different methods. They all vary in convinience and security.
Some of the also are secure but can by their nature not be a unique. For example a person can hold two credit cards or mail accounts.
So I will give you a list of the common ones with their specialities:
E-Mail validation
very common, very insecure. You can make it better by blocking "junk-mail"-services, but its still very bad. For example you can use youraccount+anything#gmail.com to recieve mail. You can block that too, but there will always be leaks. Anyone can register new mail adresses)
IP validation
Very insecure. Most poeple have danymic ip adresses and you can use proxies at any time.
Only useful when wanting to confirm the same user in a short period of time. And not even that is secure.
Cookie Validation.
Very insecure for your purpose, but very effective to confirm the same user if its in the users desire. (encrypted token are a secure teqnique)
-- lets get to the really useful stuff --
Credit card validation
Kinda useful. There are algorithms for common credit cards publicly available to check the validity of a card. But they can be broken. So some1 can generate "valid" credit card numbers. Brute force attacks are also possible.
The only way of knowing the validity is making a transaction which costs about 30 cents.
SMS Validation. Sender numbers can be faked, so it must go the other way round. The user gives their mail adress and you send an sms with a code to enter. There are gatways available, one sms is about 2-4 cents.
This teqnique is commonly used and quite useful, however it cannot guarantee that a user doesnt have more than one cell phone or numbers.
Paper-Mail Validation
Perhapst the most secure way, but rather inconvinient. Send a letter with a code to the person. As long as the mailbox doesnt get hijacked or us mail doesnt miss-deliver its very good. You can even enhance by personal or secured mailing. Google uses that for adsense accounts. The user can fool you by having multiple adresses or have it delivered to a friends place or something or give the name of a co-worker at work keep that in mind.
System-Serial validation
Download a tool that generates a checksum of the computer parts you have built in. Or just take the HDD serial number. This ensures uniqueness of one pc. But it can be cracked or have the miss comfort that the same user suddenly isnt recognised anymore because the hardware has changed.
Confirmed mails
There are providers that offer mail adresses that are verified. Meaning the user has with a legally legit way confirmed their identity which is bound to to that adress.
There are also providers which ensure uniqueness of users in their system.
This is very useful, however not wide spread.
To sum up: SMS is probably the fastest and easiest way.
I think there is no way of making sure they are unique visitors without some extensive system like creditcard validation. Identifying unique visitors on the internet is next to impossible without some kind of non-internet verification. (credit card, digID (dutch), personal call)
Related
So I have a web application which is going to collect people's opinion (People have to choose option 1 or option 2). I don't want anyone to submit their opinion twice or more, which makes me think an opinion is more popular when it isn't, so I think of several ways, but they all have their disadvantage:
Check user's IP address: user can change their IP easily by using web proxy or something like that.
Check user's HWID like what I did on another desktop application: Seem like it's impossible with php
Can you suggest me a way which is the most effective for my web application's issue? The ideal solution is having only one vote per device, but I have no idea how to do it with PHP.
Edit: Please give me your advice on this: does cookie work with web proxy? If the application stored a cookie, then the user open the website with web proxy or simply use private browsing, is the cookie still there? If it is, a combination between IP address and cookie may works.
To prevent accidental multiple submissions, require a login and save the vote in a database, or create a random unique ID that is tied to the user's session, and save that one with the vote, rejecting votes whose IDs already exist, or save a flag in the session that the user already voted.
You could use ever-/super-cookies to make deliberately faking votes harder, but you cannot prevent them unless you have some means to verify an identity and ensure that no person can have multiple identities, e.g. ID cards issued by the government with functions for eCommerce and e(Whatever), social security numbers. However, you will have to interface with an institution performing the verification for you.
And ever-/super-cookies and browser fingerprinting are vulnerable to the use of multiple browsers and break when facing paranoid users.
If you want to prevent multiple deliberate votes with low security and reliability, you could establish an identity like on StackExchange / StackOverflow, i.e. reputation-based, and prevent votes until someone has gained some reputation level.
Or you could require phone-/account-/credit-card-/payments-based verification with low level of confidence (e.g. send SMS text message with verification code to phone number, Facebook, Google, Amazon, PayPal, Stripe...) - people can have multiple phones, accounts, credit/debit cards etc.
In the end, there is no easy-to-use system for identity verification that prevents multiple identities with high confidence (that I know of).
We have a website where we need to obtain our customers routing and bank acct #'s who want to sign up for monthly ACH withdrawals. I was wondering the best way to achieve that. I thought about first making the form an SSL/https link and forcing it with .htaccess modrewrite. Currently we are emailed the results of any information submitted to the site web forms. My next concern is the email sent from the server encrypted if you use smtp TLS etc? In other words what is the best may to transmit the data from the server back to our email securely. Or is using email to transmit the data a bad idea altogether. Any help/reccomendations is greatly appreciated.
NOTE: I would like to add that we are not actually performing the ach. We are just getting the information and passing it on to the vendor to perform the ach. Currently it is a written and signed form they fax. We can continue this process. I was just looking to automate this portion only. However, it sounds best to just outsource even this piece?
The best way to achieve this is to outsource it to a financial institution which is already compliant with PCI DSS rules, local financial regulations, and the like.
I'll repeat that: do not do it yourself. Have someone else who knows what's up do it for you.
There are services that provide this: Amazon Payments, Dwolla... Why would you need to handle the actual account numbers? What you care about is that the cash gets to you, not its exact origin.
And NO, EMAIL IS NOT SECURE. Unless you're encrypting it, and if you had to ask the question, you're not. NEVER send confidential information in a plain email. (Caveat for experts: a TLS-secured SMTP session with no intermediate relays connecting to a DNSSEC-provided IP address is reasonably secure. It's doubtful that your average Joe would implement this properly, however).
In my registration process, the user registers, they get emailed a verification link, and if they click it, only then would their account be verified. But isn't this verification method too easy for the bots?
I think an email could be created by a bot, but for sure if the verification is just clicking a link, it could also be automated by a bot. I'm not sure since I haven't done this and don't care to test it just to know, but my question is isn't this verification method flawed?
I'm thinking about sending the verification code to the user as a text which they would have to copy/paste manually into a form AND the form is captcha protected. Is this a better idea? any flaws with it?
Most of the suggestions are about verifying emails and using CAPTCHAs which of course you should do, but keep in mind that none of these methods is completely bulletproof.
Email verification
A bot can easily "click" on links in any email. Copying and pasting something would be slightly more annoying for the bot author but not much. Generally email verification is just that - email verification.
You verify if the email is likely to be controlled by whoever tries to register, but of course since email is usually sent in cleartext over untrusted TCP and relies on insecure DNS, then until we're all using DNSSEC and encrypt all traffic it will be easy to sniff emails and spoof servers and clients. The important thing to realize is that using email verification you get only a certain degree of confidence that whoever or whatever you are talking to is really a user of that email address.
Turing test
Answering a question that only human should know the answer to would be still more annoying but considering that you probably wouldn't have an infinite number of questions, the bot author might redirect unknown question to a real human and use cached answers if any question repeats more than once. Answering a question like "what is 12+8" like I've seen in some websites lately as a Turing test is completely counterproductive since this question is actually easier for bots than for humans. Probably the most popular Turing test for that are CAPTCHAs but here you also have to realize that they can be fooled.
First of all people are showing methods of circumventing CAPTCHAs, for example see the Decoding reCAPTCHA talk from DEFCON 18. Many CAPTCHAs are much easier for robots to decipher since they are generated by algorithms that are trivial to reverse. The reCAPTCHA distortions are also pretty simple but the words that they use are real scanned words that was hard for OCRs so in principle it should be much harder for bots, but it is not always the case.
And there is also a possibility to display captchas that you want to guess on other websites and have people answer it for you. Also there is a black market of people actually solving captchas so if your bot author doesn't mind paying something like two cents for a dozen then no matter how hard it is for humans, actual humans will solve it anyway.
Bottom line
The bottom line is that using any of the bot-stopping techniques will always be a compromise of how much would a bot owner (a spammer or anyone else who wants to register a lot of users in your system) be willing to spend time, effort and money to do it, and how much inconvenience for your users are you going to tolerate, because ultimately you will never be able to do any automated test to tell humans and bots apart without actually annoying humans and alienating people with disabilities (has anyone ever tried to guess the audio version of reCAPTCHA?), and still your bots may actually be human-powered, so not really bots but cyborgs, so to speak.
It's an arms race for which your honest users are paying a price. Please keep all of that in mind.
The questions is what are you trying to verify? When you send a link to an email address, what you can know is that whoever registered that account has access to the email address. It doesn't tell you anything about them other than that.
So yeah, bots can create an account, and use it for registration. If you want to stop bots, then yeah, a captcha is what you need to add. Note that there's little point in adding the code to copy/paste - that's both easy for a bot to do, and also doesn't gain you anything over the captcha.
As always, security and convenience are generally competing with each other.
A link in an email simply validates that it is an active email address. Yes, it's easy for the bots to handle this. But is your service so valuable that bots will be attacking it?
A CAPTCHA is always the way to go to ensure your users are human. The additional coding and frustrations involved with it are a trade-off.
In the end, keep things as simple as possible, but not simpler.
As pointed out already, you simply have some CAPTCHA validation.
My suggestion is though do human validation before your app creates the user account and sends the verification email. Added value of your site can't easily be forced to just spam verification emails and create bogus waiting to be verified accounts.
Nothing wrong with a link if you do that.
Yes, bots can enter emails and check the responses. I've also heard of endeavors toward bots getting better at image recognition and answering captchas, although I can't say for sure how good they are. If you are really really concerned, I would go with:
Email verification
Captcha
Simple random questions (How many ears/fingers do most humans have?)
Cell phone number that sends a code via SMS
The last one might prove to be the best in eliminating bots, but it will also limit who signs up for your website. Also, the more validations you have, the more you'll annoy users and the more you'll increase the barriers to getting them to sign up, which could also be a pretty big drawback. Personally, I think captchas are a good balance of bot protection vs. user inconvenience.
Are you verifying an email only or doing a full registration?
I always verify the email account first. then once verified complete the registration process.
so add a captcha at the verify email step.
In other words, ask the user to enter their email address, enter the captcha and submit the form.
That way only real people get the verification email sent.
It doesn't prevent human bots of course.
DC
It also means you don't need to store failed/bad registration data.
One problem is a user validating with one email address and then changing it during the registration process, I handle that this way..
When a user submits their email address the data is not stored at all. Instead I use $validation_code = md5(trim($email)+$secret) to generate the verification code. That way they can't change the email address on the actual registration form. The email and verification code is carried as a hidden field to the end to validate the email address. if the email address is altered from the verified one, registration will fail as the md5 no longer matches.
DC
I ran into similar problems with verification emails and testing. If you want to end-to-end test email verification try EmailE2E.com — it's free.
You can send and receive emails from randomly generated inboxes via an API.
It's perfect for testing Firebase, Amazon Cognito, or other OAuth providers that use email verification codes during sign up. Plus it has clients in Java and JS.
I'm currently developing a system which has a functionality where clients can view details of their purchases/renewals/etc by supplying a PIN "number".
A PIN is being used instead of login information because of the type of clients we're targeting. The PIN is printed on documents sent to them.
The view shown when they supply the PIN does not reveal highly sensitive information such as credit card etc, but less sensitive one such as product name, type, price, barcode, repairs etc.
The issue in question is the PIN. I opted to using a random 5 character PIN (0-9, a-z A-Z) - case sensitive.
I'll be removing some homoglyphs ('I','1','l','0','O','rn','vv'), so the actual number of combinations is actually lower.
I've got a couple of questions about this:
Is this practice acceptable?
Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?*
Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
*Should I make use of a captcha system?
As for the CAPTCHA and lockout - I'd go for the CAPTCHA, and delay 1) the clients that fail CAPTCHA, and 2) invalid logins: before checking, sleep 1 sec on 1st attempt, 2s on second, 4s third, 8s on subsequent. This won't inconvenience normal users too much, but it will slow down an attacker significantly. No matter what you do, people will get it wrong - no need to ban them outright.
The checksum - might be useful as a 6th character for detecting typing errors, not for security.
As far as the password strength goes, this is a weak password - I wouldn't use this as the only form of authorization for anything stronger than "sharing pictures of lolcats" - consider a longer one, or your clients might even accidentaly access each other's data (and they tend to get really upset when that happens: "you mean that anyone could see my data like that?!").
A PIN is being used instead of login
information because of the type of
clients we're targeting. The PIN is printed on documents sent to them.
Very strange, but yeah could write it like this. I think you should really reconsider if it is really necessary. But if I understand you correctly you sent the document via snailmail? For example Isn't it possible to send the user a PIN and next have them sign into openID(LightOpenID). I would lock it down to just Google's OpenID provider because these accounts are "safe". This way you have added another level of security. Also Google uses captcha to verify account(make it
"safe").
Is this practice acceptable?
I think it is acceptable, although very strange.
Should I write a lockout mechanism to
"ban" traffic from IPs with a large
amount of failed attempts?*
I think you should write a lockout mechanism should because brute-force hacking password is already easily accomplished, but brute-force hacking a PIN can be done without any effort at all. Although I don't think you should do it via IP, because the end-user could sit behind a router and then he would be blocked. Also hackers could have a botnet to perform these kinds of attacks.
I read today about HashCash thanks to stackoverflow.com and I also found it very interesting. Maybe you could use that to protect yourself against attacks.
Should I write an error checking
system (similar to Luhn's algo in
credit card numbers)?
I don't think so.
Should I make use of a captcha system?
The only true way to prevent automated attacks is CAPTCHA's, so I think you should. Google/Twitter/etc aren't using CAPTCHA's because they are user friendly, but because that is the only working way to stop automated attacks. If you would implement my system that PIN with OpenID from Google then you can skip this step, because Google already has you covered.
First of all, ask not only for the PIN, add something simple the customer knows, like with snail mail systems where you're often ask for your ZIP-Code. That sorts out people that do not know the somehow "shared secret".
The captcha, if it's not annoyingly hard makes sense as it helps to reduce "guess" attempts by bots. As Stefan mentioned, banning by IP is problematic because of shared IPs.
You could also implement some kind of "tar pit" when form posts are wrong based on your error checking, e.g. you delay the processing of incoming connections. A simple algorithmic error check helps you to avoid a useless database lookup of the given PIN.
1) Yes, depends on target audience though.
2) Sometimes it makes sense, sometimes it won't work due to how the system is used, and how many clients are on a shared IP number.
3) What value would it add? Won't that just help people trying to find a working PIN?
4) Depends on target audience, and what kind of captcha.
yes but it depends on the value of the information,if the information value is hight and you think that someone may try to break in you should consider additional protections
It may be a good idea if the information you are protecting have an hight value,in this case you must warn the user that he have a limited numer of possibilityes,create also a log file to monitor failures on code typing and consider that if the user is behind a NAT a lot of user may use the same ip(all the user on an office or in school for example,also connection like fastweb use one ip for a large group of people) so don't block the ip for a long time(15-30s every 3-5 fails should be enoght to avoid brute force attacks,you can double it every time the user fails a second time)and,most important,block only the code immission not the whole site.
it's not needed but you can implement it,as i sayed it also depend on the value of the information
it's a great idea to avoid proxy and crawlers but i recommend something different: use an image with a question like " five plus 2 =" or "what's the color of a red apple?",they're a lot more hard to understand by crawlers but a lot more easy for users.
I recommend also you use mt_rand() to randomize the pin(a lot more efficient than the default random,it's statistically correct random and it's integrated in php as default),the homoglyphs removal should be a good way to avoid error typing but i may recommend also to create a longer code with separators like
AXV2-X342-3420
so the user should understand that's a code and easly count how many character are left or if he entered the wrong code.
I may avoid case sensitive pin because upper case characters are more easy to read and some user will simply paste it lower or upper case only even if you write clearly that the code is case sensitive.
The axiom "If you're going to roll your own security, you've already failed," applies here.
For your 5 character [0-9, A-Z, a-z] pin, you're generating less than 8.27 bits of entropy (64 310 = 2^n). [fixed]
It will take less than one day (a 1,000 guesses/sec, which is very slow) for an attacker to break your system. Is that acceptable? Maybe for trivial systems where bypassing security has very little impact.
Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?
IPs can be spoofed.
Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
That would actually decrease the number of bits in your entropy, making it easier to break into your system.
Should I make use of a captcha system?
If you feel you need the exercise. Captchas have been broken and are useless for anything other than as a speed bump.
Update
Unfortunately, there is no cut-and-dried solution for computer security, as it is still an immature (undermature?) field. Anyone who says, "Oh, do this-and-this and you'll be fine" is skipping one of the most fundamental issues around security.
Security is always a tradeoff
The ultimately secured system cannot be accessed. On the other end, the ultimately-accessible system has no barrier to entry. Obviously, both extremes are unacceptable.
Your job as a software developer is to find the sweet spot between the two. This will depend upon several factors:
The technical expertise of your users
The willingness of your users to put up with security
The cost (time and money) to implement and maintain (i.e., a more sophisticated system will generate more support calls)
The impact a breech would have on your users and company
The likelihood of a breech: are you the US Department of Defense? Visa? You're probably under attack now. Bob's Bicycle Shop in Ojai, CA is on the other end of the spectrum.
From your question, I take it that you're effectively generating their "password" for them. What if you flipped it on its head? Make the pin their account and the first time they log into your system they have to create a password* that is then required from then on.
*Yes, if this is a bank, then this is not a good idea.
I work at a hospital and have developed a way to estimate the total patient financial responsibility for services, after insurance has paid it's obligation, and before any services are rendered. A lot of patients are calling for quotes, and I wanted to find a secure way to email those results to the patient at their request.
I'm considering removing all patient information from the generated quote, so there would not be any security concerns, but would like to find a way to encrypt the email, send it, and allow the patient's email client to decrypt the email.
I'm not sure how to use security certificates, though they might be the best option for me, even though I'd have to jump through corporate hoops to be granted access to internet facing hosting for certificates, all applications other than email are hospital side only.
I'm also considering creating a PDF from the generated letter and encrypting the PDF, assigning their last four of their social, or some other private info they've shared with us during the quote generation process, as their password.
You would be better off sending a link to an SSL encrypted site that has all the information. It would not require any additional software on the client side, and would allow you to have a bit more control and accounting of who is accessing it.
You must of course secure it with username/password of some kind, you could even just use their social security + a generated hash sent in the email. The hash prevents a user from guessing random ssn's.
If you're employed by a hospital in the USA, you had better not try to email protected health information. (Similar things are true in other countries.) Even if you scrub the patient's name out of the message, you'll definitely have the patient's email address in the message (duh!). You'll most likely have diagnoses, dates of birth, dates of proposed care, medical record numbers, or account numbers. That's all protected data. Bad. Bad. See here for the regulations, which are rigid.
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html
If you want to do this, you must use TLS (https) security, and you must go to some length both to ensure that the person logging in to your secure web site is who they claim to be, and you must log accesses.
Please, if you value your job and your savings account, check with your hospital's privacy officer before sending emails with PHI in them. The ARRA 2009 law makes individuals personally liable for breaches even if they work for corporations. Plus, your hospital does NOT want its name in lights here.
http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/postedbreaches.html
You could use encrypted email, as long as the unencrypted part (e.g. the subject line) only said "here's the information you requested" or something like that. But, you know, many persons seeking medical care won't be able to cope with a complex addin to their mail client software.
The PGP company offers an encrypted email gateway system that some people with PHI use.
http://www.pgp.com/products/universal_gateway_email/index.html
But you should still check with your privacy officer.
I accomplished this about 10 years ago using PGP. GPG is a similar library.
These options may be way too involved for an older user though, as I believe they both involve the recipient installing a certificate of sorts on their end.
Might be a good place to start looking...
From what I know, this is essentially impossible unless the recipient is also using the same e-mail client. The problem is that even if you encrypt on your end, the recipient will received a garbage message simply because they don't have the functionality to decrypt.
While I was typing this, TomWilsonFL posted information on a possible encryption method, but you will still need to provide the recipient an application to decrypt the data.