I need to implement captcha functionality like in Gmail.
If the user has requested first time, no captcha image will be shown.
But, if user is requesting second time to login, (User has entered wrong password first time) need to show the captcha.
Please let me know how to check if the request has come from the same user so that I can implement some business logic in my spring classes.
Why are you trying to tie up login attempts to concrete user? If I'm a malefactor and I want to guess the password, I'll use the bruteforcer which can use proxies.
Each time I'll have new IP, so your captcha will not work for me.
In my opinion the better solution is to store counter of incorrect login attempts. Each time anybody inputs wrong password for particular login-name, you increase the counter value for this login. If password is correct, you set this value to 0. If counter value more than 0, you'll show your captcha.
Attach the counter to the HTTP session. You may required to store the session on the server side, and in a distributed ENV, you should SYNC the HTTP session across servers. You can also store that info into Client side cookies.
At server side(servlet) create HttpSession
HttpSession session = request.getHttpSession();
and keep count of hit inside this session
session.setAttribute("count",i); //you can use getAttribute() method to check the count.
There are a couple of ways to do that:
When the page is first loaded, start a session (or send out a coookie). Use a count against the session/cookie. You can spit out a captcha once you find the cookie for the second time.
Use hidden form fields. Put a special name/value pair that you can identify on the second request and send a Captcha across.
Use AJAX! This would involve using an XMLhttprequest to submit your form, if invalid, you can show a captcha! This would probably give you more control, but at the expense of re-working a bit.
The last two bullets are assuming you want captcha on wrong passwords rather than on a different request/page-reload.
Every one of the above methods has its own pros and cons. You need to choose one or a combination or more than one according to your need.
Related
I allow users to register on my website using a registration form.
Once form is submitted a token will be generated and will be sent by email to user, they need to click on the token link to activate their account.
My question is that if I do it, do the malicious codes can still send multiple emails to my website to register, should I use Captcha to protect the website or there is any other method ?
If all you want is to prevent double submissions, you can generate a unique token for the form that you check on submission. This requires some thought if there are multiple forms per page. Also, a simple method is to just disable the form/button on submission. This is even more effective if the form is submitted via Ajax (so that the action parameter of the form can be absent and thus not easily harvestable).
If you want to prevent automatic submissions (by bots), while Captcha is probably the strongest of the common methods, it is also very user-hostile. Instead, unless you have a reason to believe your site is being specifically targeted, it is usually enough to just use honey-pot fields (invisible fields that a human would never fill but a bot would) and hidden fields that you fill with a known value after a short delay using JS (a bot wouldn't normally execute JS nor take time to type into fields like a human). Simply doing an Ajax submission is also usually enough. I recommend using one or a mixture of these methods before falling back to Captcha.
Captcha is one of the standard methods.
Another way is do not do a direct submit of the form.Use AJAXfied server calls sos that form does not get posted by itself but has some data scrambling of inner fields & delays the submissions.
$("#contactForm").submit(function(event)
{
/* stop form from submitting normally */
event.preventDefault();
/* get some values from elements on the page: */
var $form = $( this ),
$submit = $form.find( 'button[type="submit"]' ),
name_value = $form.find( 'input[name="name"]' ).val(),
email_value = $form.find( 'input[name="email"]' ).val(),
phone_value = $form.find( 'input[name="phone"]' ).val(),
message_value = $form.find( 'textarea[name="message"]' ).val();
/* Send the data using post */
var posting = $.post( "contact-form-handler.php", {
name: name_value,
email: email_value,
phone: phone_value,
message: message_value
});
posting.done(function( data )
{
/* Put the results in a div */
$( "#contactResponse" ).html(data);
/* Change the button text. */
$submit.text('Sent, Thank you');
/* Disable the button. */
$submit.attr("disabled", true);
});
});</script>
I'm no expert in this matter, but the solution seems rather obvious to me:
Everyone uses CAPTCHA. There's simply no other way to protect your server from automated attack. It won't save you from DDoS, but will handle pretty much everything else because CAPTCHA is, well, CAPTCHA.
You do have multiple CAPTCHA solutions available though, so choose one that suits you best.
As Velis mentioned, easiest way is to use Captcha.
Other solutions exist but can be easily beaten if bots are targeted for your website, for example, having an hidden field like "re-enter email" which will be filled by bots, but can be caught on the server side and registration can be rejected.
Certain, complicated methods also exist, like recording mouse clicks or time taken to fill the form, but these require significant JS work and can be overkill until your website becomes a bot target.
Captcha is one plausible solution, but most humans don't like it.
How about instead if you add some intelligence to your system?
Implement a cooldown between emails. Before sending an email, wait one minute. If another email request comes then wait another minute and don't send the first one. (This could be another form of attack but only if this is the only line of defense).
Would a person try to register 30 times in the last minute? No.
Would a person re-register if the last register was successful? No.
You can also combine these with the IP of the registering user: Would a user try to create 10 new account for other users from the same IP in 10 minutes? Unlikely.
If this is a corporate website and you MUST prevent the email spamming, then consider secondary ways of communication. For example, if you have the means, you can request the user to SMS the email address to a specific number, which would create a reset password request.
You could also, upon the user completing the registration, generate a list of numbers that should be used to retrieve the account. Something like: "If your account is lost, it can be retrieved by entering one of these numbers into the RETRIEVE field" And then provide a list of numbers that would be confidential to your company and the customer. The same way Google does it.
Although these mechanisms can become complex, they will be smarter than any captcha; will be easier to adapt, and more comprehensive. On the plus side your users will thank you for not having to read twisted images of numbers and letters.
Assume I have a single servlet in a web app, and all users need to be logged in before they can do anything. So in the get and post methods there is an if block to test if the user is logged by trying to extract a session attribute in to process request, and else to redirect to login page if not logged in.
Given this scenario, is there a way an intruder can manipulate the system to gain entry without knowing the password? Assume the password is hard-coded into the servlet. If yes, where would he start?
I would look at http://docs.oracle.com/javaee/5/tutorial/doc/bncbe.html#bncbj and the section linked from that section about specifying authentication mechanisms.
See also (on Stackoverflow) Looking for a simple, secure session design with servlets and JSP and How do servlets work? Instantiation, sessions, shared variables and multithreading
In short, you don't need to do much yourself about checking for a session attribute if you use the mechanisms described on those pages. Your login form can be used in the 'form-login' configuration requiring authentication.
The key of security is around your comment extract a session attribute -- how are you doing this? Are they sending you a query string param? Are they sending you credentials in the method headers?
To #Hogan's point, unless this is over HTTPS the answer is: "No, it is not secure. A man-in-the-middle (MITM) can get the password from your submission and simply re-use it to mask its own nefarious requests".
If the communication IS done over HTTPS, then you should be fine. Having a single hard-coded password is fine, but consider the case where the password gets compromised; now every single client/user/etc. has to change their code.
A better design is to issue clients a key they can send along with their requests that you can use to identify who they are and if a key gets compromise, re-issue a new one to that user/client/etc.
This assumes traffic is over HTTPS
If traffic is not, a lot of this breaks down and you need to look at things like HMAC's. I wrote this article on designing secure APIs -- it should give you a good introduction to how all this nightmare of security works.
If your eyes are rolling into the back of your head and you are thinking "My god, I just wanted a YES/NO", then my recommendation is:
Require all traffic to be over HTTPS
Issue individual passwords to each client so if one gets compromised, every single one isn't compromised.
That should get you pretty far down the road.
Hope that help. This topic is super hairy and I know you didn't want a history lesson and just want to solve this question and move forward. Hope I gave you enough to do that.
Hi i'm working on play20 framework with java application.For that
i want to implement "remember me" functionality like gmail or facebook
without cookies . i don't know how to start .Can any one help me in
that ?
Thank you in Advance.
Why do you want it without cookies? If you'll remove all google.* cookies it will not remember you as well.
Of course you do not need to store credentials in the cookies to keep the user logged in. Most probably you need to save some kind of ID in the database for each logged user and then store this ID as a cookie. When user comes back you have to check if stored cookie fits any of the user and if it do, just consider the user is logged in.
Of course to avoid brute force attempts you should also create additional validation cookie(s) and each time check if sets of cookies matches each other with server-side comparison.
I think you definitely need cookies. However RememberMe isn't so trivial as it's looks. I implement one for permsec in play2.0. After finish it, I found this article, which shows a lot of problems with stolen cookies.
I don't think it is possible without using cookies. If you want to implement this functionality with cookies, when user clicks "remember me" just let the expire date be in a distant future.
I have a situation where ideally I want to be able to log-in to a secure area using a Java application.
I would like to make an HTTP request and check the response to see if I need to do some kind of authenication before I can actually get the response expected, instead of effectively some login page. The complication is that the server that responds will not always be the same - the user of the Java app specifies the URL - and the server may be using some kind of single sign on authentication or the web container's.
I don't know the field names for the username and password fields or the action of the form, is there a simple way to obtain this kind of information from the URL?
I see the URLConnection object has methods getPermission() which has a method getActions() but are not suitable, anything that might be?
I guess example things I am looking to determine:
Does the response require authentication?
If so; what type / which servlet? e.g. j_security_check, josso single sign on, ...
And then some way of authenticating the client
And finally managing the state of the authenticated user for other requests
Do I need to know the attributes of the login form before attemping to login? And then, is the onoly way of verifying permission to the requested resource to manually manage the cookies?
Thanks in advance.
What I did in the end was sent a request to a page, checked for a login form (a form which has two visible fields, one of which is of type password) and obtained the form field names from that.
Posted the values back (along with hidden values and JSession cookies) and saved the cookies returned by the server. This works! And then as long as I send, with every request, those cookies, I can access sercured pages.
Thanks.
Also - why is my reputation score around 100 less than when I last logged in, despite not getting down voted on anything??
It sounds as if you are trying to create an SSO process in the client. I don't fully understand your design here, but when I see clients that are effectively allowing the user through to the server they usually just provide a checkbox "requires authentication" if the user clicks yes then he/she would fill out username/password fields. You will need to know before hand what the server is expecting so you can code in the required fields. I don't believe there is any Universal method of authenticating to an unknown service. If there were we probably would have solved SSO a long time ago. There are a huge number of authentication methods, many of which are custom. So, how could something determine what fields and such a server requires in order to authenticate?
I think if you are asking your users to provide an URL then you by definition require them to know something about how to authenticate to the server. Assumptions could be made, say, if the URL were svn:// or ldap:// or the like...
If you are providing the user with some enumerated set of services to choose from, say in a drop down, then you have the control to try and abstract the interface and hide the authentication details from them.
I've already read most of the questions regarding techniques to prevent form spam, but none of them seem to suggest the use of the browser's session.
We have a form that sends an email to given email address and we didn't like the idea of using "captchas" or Javascript, as we wanted to keep the user journey simple and accessible to those without Javascript.
We would like to use the session object to help prevent form spam. Our webapp is developed on Weblogic Server 10 using Struts.
The solution being, when the form loads, it would set a variable in the session object. Once you click submit, we check if the session for the variable. No variable, redirect to the form. Variable exists send the email.
I would really appreciate any opinions/reasons why this might be a bad idea, so we can evaluate this solution against others.
Many thanks,
Jonathan
There is nothing to prevent a spammer from automating the process of downloading your form (thus generating the cookie) and submitting it. It may impose a slight burden on the spammer, but a trivial one.
As an example, a form can be easily downloaded and submitted, with cookies preserved, using a command-line tool such as cURL. This can then be run from a script repeatedly.
Session objects can, depending on implementation, be relatively heavy in terms of resource usage, as well as somewhat slow. Additionally, the spammer, if they realize how you are blocking them, can simply start a new session every time they hit the form by not sending back the session cookie.
So, because that technique relies on the client to behave nicely, and the expected behavior is fairly easy to prevent, it is possibly less useful than some other ways to solve the problem.
Thank you for your reply cdeszaq, but I'm not sure if you mis-understood my question.
For the form submission to complete successfully, clients will be forced to load the form to set up the session object correctly. Only when the session is in the correct state, will it be possible to send an email.
If the spammer is not sending back the session cookie, then they will not be able to spam my form as they haven't gone to my form page that creates the right session.
I agree that using the session object would create extra resource. Our implementation would simply, (using JSP) call session.setAttribute("formLoaded", true); and in my Struts action I would simply use session.getAttribute("formLoaded"); to check.
I wonder if this might work:
Each time you render page/form, create a random bit of text
Put that text in the session
Include that text as a hidden field in the form
User submits the form
Action compares the hidden text to the value in the session - if there's a match, send the email
Since a hacker wouldn't be able to put any random value in the session, they wouldn't be able to spam. Right?