I would like to know more about the solutions to restrict registering for a website for humans only.
Captcha may seem a proper solution but as it turns out it's not as good as it sounds.
And it's not a problem if a solution is not an option for blind, deaf people etc..
My newest web app uses a process that makes this really easy for the user and secure for me.
User goes to login page, enters their email address and clicks an "I am signing up" checkbox.
The user clicks "register", their email address gets inserted to a temporary SQL table (called signups) and an email with a verification link is sent to the email address.
The user clicks the verification link which takes them to a "create password" page.
After the user creates his password, the email address and password are inserted into the users table–and the entry in the signups table is deleted.
This makes it easy and reliable.
The signups table also includes a random SHA1 hash (for the verification link), a timestamp set for 12 hours after the sign up, and IP Address.
All entries in the signups table that have an expired timestamp get removed at certain parts of the day.
Update
Since writing this answer, I have found that keeping a signup form secure from robots is a never-ending battle.
As time goes on, new technologies and methods are being developed to circumvent security measures. The best thing any dev team can do is periodically be checking the quality of signups, and thinking of ways to make their signup form both more secure and intuitive to use.
Yeah, it is a good bit of work and resources that go into it, but having confidence in your signup form and quality of signups is well worth the expense.
Depending on how targeted your site is, using a honeypot can be quite effective.
In short, you have a field on your form with a common name -- let's say email. Your actual email field has some other random name like larp.
Hide the email field using CSS, and include a text label instructing users to leave that field blank, should they happen to see it.
If any registrations come in with the email field filled in, send a success message back then drop it.
Verifying the e-mail address and allowing only users who have verified their e-mails is the easiest and quickest solution.
You could have users listen to an audio file, and enter the word into a text box. That's what I wanted to do for phpBB3, but alas, they do not allow HTML markup for their verification questions. Alternatively, you can do defense in depth, and have a CAPTCHA be only part of the process.
Instead of captcha (typing in words displayed in an image) I've seen websites that require you to answer a question, usually basic math. I haven't implemented these, but I've seen them several places so it must be something that's a plugin for various CMSes and soforth.
Bottom line is, any system will eventually be circumvented. You can minimize bot-registrations, but I can tell you from experience that there are people out there who will pay other humans (who can pass just about any test) money to sign up for web sites - the pay is generally really poor, but there are always people who will find that acceptable.
So along with whatever solution you use, you'll want to periodically re-evaluate that solution, AND you'll want to have a human being review new registrations (maybe once a day?) to weed out the few 'bots that do get through.
Related
I developed an application in which all the processes of organization is going to be handle online .
There are some processes which were run manually and it took time , now it is going to approve or disapprove online.
Let say there is an document who is going to be approved by HR ---> ADMIN ---> CEO.
Now when some one initiate a request application send two links to HR manager which is approve or disapprove , and HR can perform their action by clicking those link.
What is happening it if HR manager send this links to someone else , SO , That person can also approve or disapprove the process , although he is not the right person to do.
I can stop it by implementing authentication process on those two links , Than every authority must have to login in the application . which i don't want.
Is there any way that i can pick the email id of the person who click that link , so i can compare the email address on back end ?
As I see it you have 3 possible ways of doing this:
1: Implementing an authentication process
This is the best approach in my opinion as you can be sure that the person who should approve the process is the person actually approving it.
The con with this approach is that the users will have to log in, but you could implement this in such a way that they rarely have to, for example they could stay logged in for one a month or longer.
2: Using a link with a one time token
This is basically the approach you mentioned with the con that you mentioned, namely that someone can just forward the email and someone else can then approve it.
The only way in your case for this to work is if it's enforced from the top down, as in management could impose a penalty if such an email is sent to someone else. But this is rarely a good strategy and would be difficult to enforce.
3: Approve and Disapprove with a reply email
I think this approach might be the closest to what you're looking for, but as a disclaimer I've not tested something like this before.
You could setup the links in such a way that clicking on them will open a new mail screen with certain things populated, for example you could populate the subject and the address to send the mail to.
Example link: Approve
Then within the system you're creating you'll have to monitor that mailbox and then parse any email received, using the from address to validate if the correct person has sent the email.
A big note with this approach is that the from address in an email can easily be spoofed, so if you want to take this approach, I'd recommend at least adding some sort of random token in the email as well that will be validated on the back end.
Even with the unique token, there exists another vector of attack, although it would take some work. Let's say the system sends a mail to Alice because she needs to approve or disapprove something, she forwards the mail to Bob. Bob can't click on the link and send the email as is, because the system will see that it came from his email address, but what Bob can do is click on the link to see what the subject should be, and then spoof Alice's email using a spoofing site. The system would then see everything as in order because it will look like the email came from Alice.
Example spoofing site: https://emkei.cz/
Let's say, i have a website and it has one button: click me, and also a counter which counts how many times people clicked on the button.
The thing is, how to validate if the clicker is a real person, that he clicked only once e.t.c. ?
Ip's can be changed. Also, it's not a good choise to make a whole account system for a single button.
1.- You can save the count in the cache to make it accessible on the backend side.
2.- In the Frontend you cannot access to the IP, so you won't be able to check at that level.
3.- Maybe what you're looking for is a button with a Post in a login website, then everytime the button is clicked you can send the post with the user information and saved.
4.- To validate if'¡ it is a human you can use Google Captcha.
Hope this helps you!
You can use Google Invisible ReCAPTCHA. It's not 100% reliable when it comes to detect bots (it has been proven mutliple times by the past) but still very efficient.
However, to detect if a single person have clicked only once, there is no viable solution I think. You can maybe add a cookie and check if the cookie exists but it can be easily bypassed by simply deleting the said cookie.
To authenticate a unique device, you can store MAC, IP address, and User Agent. Of course, all those can both be spoofed to allow multiple clicks. That solution would also limit to one person per device, which may not be your intent. Storing User Agent with the MAC address is more difficult to get around than a cookie (that can be deleted).
You can eliminate the most common bots by their user agent, or you can use a CAPTCHA.
You authenticate persons by email account or OpenID, but I assume you want to make clicking the button as easy as possible.
This is the first time I'm building a website with complex login\signup dialog with backend security feats such as email validation with an activation code and ban registration for too many bad login attempts.
I thought I was finished with building the security architecture, but then this came up: How do i block malice users from abusing my new user dialog.
The only solution I could come up with was a cookie handed at the moment of a successful registration with email address that was last used for registration, backend recognizes this cookie on a new registration attempt and prompts the user about the new findings. Maybe even takes a timeout before responding.
But that only makes it intolerable for 12 year olds, it probably wouldn't happen, but someone with even basic skills and good enough reason could brute register thousands of emails with a simple script, I cannot block a user from having as many accounts on my website as he does have email accounts (amirite?)
Any suggestions?
Try integrate a Captcha code or something the user has to do, e.g. a small math. Randomly generate something the user has to do to be able to register. Usually this annoys most kiddies because they would have to change their scripts.
Captcha code is usually something pretty common on public website registration pages...
Also maybe try to register email together with the IP and log IP addresses logged in on that account and prevent new accounts for that IP.
You could record the IP address on registration and if you get a high amount of users from the same IP address you could block it.. saying that spammers can spoof their IP.
I would recommend:
CSRF
Verifying email address.
Record all IPs and block any if necessary.
If all fails CAPTCHA, it won't flush out everything but it kills a lot in my experience.
One possibility would be to generate a random number server side and store it in a session variable which must be returned along with the data, or better still some hashed version of the random number eg. md5. This can be verified by the server.
This means that you only get one attempt per request, kiddies would have to adjusted scripts to suit your site. You could even restrict the frequency at which the numbers can be generated per session.
As described here http://blogs.gartner.com/avivah-litan/2010/04/22/watch-out-transaction-signing-is-being-socially-engineered/
The way the transaction signing that was compromised works is that
once a payment request has been initiated by an online banking user,
the bank asks the user to sign his/her transaction on a dedicated
out-of-band EMV CAP reader with the user’s EMV Chip card inserted. The
user is asked to enter certain codes and values on the reader
confirming the currency amount to be transferred and the account it is
to be transferred to.
Well the crooks knew when the transaction signing was being initiated
and simply put an iframe up on top of the user’s browser that changed
the values to be entered so that the users ended up typing in the
fraudster’s bank account as the destination account rather than the
one they intended.
Something to think about when it comes to transaction signatures –
demonstrating the need to keep the entire process off the PC (in this
case) and on another channel entirely.
Can you explain how it is possible to "put an iframe up on top of the user’s browser" and how to prevent that kind of fraud technically ?
It's not clear from the quote, but it sounds like they are talking about consumer endpoint compromise. The user has picked up a banker trojan so their PC has become an untrusted device which can display misleading information. In this case the trojan operators changed the displayed destination account number so that funds would flow to a different party than the one the user thought they were crediting.
The point is that a complete user interface for making secure decisions must reside on the trusted device. Typing information from the PC to the secure device gives the user a chance to check the information is correct, as does a device with an on-screen display of information being authorised.
But there is a missing piece in that the consumer doesn't usually know that the account number they are typing is genuinely that of the party they mean to credit. Unless they've done many transactions with that party before such that they can remember the account number and spot it when it's wrong (and even then that wouldn't necessarily raise flags).
To correct this, the account ID would have to be something recognisable, something like a domain name whose issuance is controlled, rather than an arbitrary number. That would cause problems for any standalone device where you had to type the information, though, as it would then need a full-size keyboard. You could do it with a display-only device, something like Germany's TAN generators that read information off the screen, or you could do it with a very long account number that decoded to something readable, signed to prevent unauthorised changes.
Once the entire decision takes place on the secure device, including amount to transfer and the user-verifiable destination, the problem of the untrusted intermediary (your PC as a man in the middle) is solved and transaction is safe.
Although that information doesn't include the purpose of the transaction, so you could still imagine an attack where a reseller changed the actual items you were purchasing at a particular store, without changing the cost!
This is a sample of an XSS (Cross-site script) attack.
Say for example, Friendster, which had a lot of XSS "holes" before, particularly in the profile page. I can inject a script in my profile page, and make my page look like a login page.
Once another user looks at my profile, it looks like a Friendster login page! Then the user types his username and password not knowing that it was a fraud page. The entered values would be routed to the my server for storage, while the user gets redirected to the actual page.
In reality, the user was never logged out. The user was made to believe that it was a legit page and was made to reveal the account details.
To prevent this, you should not allow arbitrary HTML as well as scripts to get through your site. There are a lot of entry points for attack, usually input boxes that don't have thorough validation. Event SSL'ed sites are not safe if an injected script exists on the page.
I am working on a website and would like for my users to be able to give feedback as easily as possible. I know one way but I've always hated it:
Click Here to be annoyed!
Is there a way in JavaScript or HTML to allow my users to email me without having to go through a lot of trouble?
A CONTACT FORM:
avoids spam bots that pick up 'mailtos'
allows you to validate that the form user is 'human' (optional captcha)
gives you total server-side control over data format
allows you to change your email easily from the server, anytime
hides your favorite, real email from your visitors/members/site users
gives you the option to control the topic (via select menu, etc.)
gives you an opportunity to have the user check off something extra
e.g., a survey question, subscription opt-in, interest in services, quote, etc.
gives you an opportunity to return a thank you (or sales page) after submission
gives you another opportunity to look professional
There's no question the link is the easiest initially-- a simple click; but, all things considered, I whole-heartedly agree that a contact form is the way to go for most purposes, for the reasons I listed above, and more.
Well, since Tom challenged me, ;) Here are a few copy-and-paste contact widgets that you can have up and tested in a minute or so.
Some Customizable Flash Contact/MailTo Widgets:
http://www.widgetbox.com/widget/contactify-widget-beta A customizable contact form. The style is highly customizable.
http://www.widgetbox.com/widget/contact-emailer-version3-rajwidgetbox
Use this gadget in your web site's
contact page. Avoid spams by not
providing your email address in your
site or blog. This gadget is highly
customizable. This uses image
verification code feature. Multiple
languages are supported. Version 3.
3300 downloads
http://www.widgetbox.com/widget/ultimate-antispam-email-link
Now, if you really do not want a
form, but do want an email link that
spam bots cannot pick up, here's the
widge for you. In the custom area,
you define your parties and mailto
addresses. It's a simple flash
button, so the user doesn't see it
until it opens their mail client.
The way you describe is the easiest way in my opinion.
If you want the email typed up there in the page like a form, you might want to create an email/suggestion form or alternative.
You can provide a multiline text box for comments and a submit button, POST the text to your server, and then mail it to yourself on the server. That spares your users a trip to their mail clients, at the cost of depriving you of a reasonably-likely-valid reply-to address.
You could even use AJAX and spare them a screen refresh.
Google Docs supplies creating webforms that can be easily embedded in websites. It collects all data in an on-line spreadsheet which you can download at anytime in various formats. You can even set e-mail notification if a visitor filled out your contact form.
I would create a form that users can provide feedback in, and then have your server write this into a database. Writing to a DB is likely going to make it more efficient for you to wade through feedback. Having users fill a form instead of sending you free-form email also help you enforce some kind of structure on the feedback or the metadata associated with the feedback (bug/feature request/comments, etc).
The most reliable way would be to send the email with the help of some server side processing.
You can also do it using an HTML form with the help of the action attribute:
<form action="mailto:user#example.com">
...
</form>
But this method may not be reliable for all browsers.