I'm writing a web application in Java where at some point user can enter there email address to receive an email. My question is about the verification of this email address (so it's not about the validation!). I'm tagging this question also with google-app-engine, because the application will live there, but I don't think that matters too much.
Anyway, for people who have a google account I use the app engine's User API to verify that address, but for other people I would like to send a verification email, that provides them with an URL. Very standard I would think, but are there also standard ways to generate the URL? Or is just creating a hash of the email address, storing that in a database and putting it as a parameter in the URL sufficient?
I wouldn't use e-mail hash in verification e-mail. That would be to easy to guess and someone could actually try to falsify that.
If I were to implement it, I would add random GUID and store it to the DB for verification. I don't know if it is standard way to do verification or not...
Create a servlet that will check, given a key (say, some random string), whether that key is given out previously. The key needs to be crytopgraphically secure so that it cannot be guessed by an attacker wanting to pose as somebody.
Then, when someone signs up with an email, you send a link containing that key to the address they claim they own. If at some point in the future, the link you send arrives at your sever, you can record that event, and be confident that the email address is a correct one.
Related
Story for context:
I have an ePetition type service running on my site which I email people a link where they can 'agree' to the petition. This link will only contain the 'petitionID' and 'username' of the person who sent it.
This information isn't particularly sensitive but I still require it to be tamper-proof because I want them to be able to accept without signing in or storing values in the database.
I thought of using Java's String.hashCode() function.
Maybe having the url as: username, petitionId and then a hash
www.website.com/accept.jsp?user='username'&id='petid'&token='1039678106'
The token could be made up of username + id(from the link) + datePetitionStarted(like the salt not exposed in the url) like:
String test = "mike.Who#petitionwebsite.com+1524+09/02/2016";
System.out.println(test.hashCode());
This would give me a hash of '1039678106' which means server side, I can take the ID parameter, the username of the person and use the datePetitionStarted, get the hashcode and compare them.
Do you think this is a valid way of preventing tampering?
I'm really after a token-type method of accepting petitions so if anyone has any other ideas that would be awesome.
thanks,
Mike
Here's what I did (which is practically tamper-proof). I don't use java script as users can disable it anyway. I simply create a UUID, (which is stored in a database next to user details) and then create a link sent in an email during the registration process.
http://my_domain_name/Activate?key=6faeecf5-9ab3-46f4-9785-321a5bbe2ace
When the user clicks on the link above, the server side code checks that this key actually exists in the database, in which case it activates the user account.
While the String.hashcode() may return the same value for the same string across instances, this is not guaranteed.
Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution
of the same application.
API docs for Object.hashcode.
As such, if you were to down down this route you should use your own hash.
I need to encrypt a string at client side and send it to the server.
Once there I need to decrypt it.
Is the Using Password-Based Encryption the best solution?
I need it because I have a voting mechanism, where I send ajax posts to vote an entry.
This mechanism use the Facebook id from the current user. My goal is to encrypt the FB id from client side to avoid that they hack it by sending requests with differents ids.
If a second post with the same id is sent I will block the vote.
Once the id is decrypted I will check if it is a real FB user using the graph.
Javascript encryption won't help here. Any good detective/hacker can see how it's all done on the client and see what the data was before it was encrypted and see how it's encrypted.
The only way to prevent a user from voting multiple times is to have the vote tied to an account or token that you can both verify on your server and tie to a particular user that isn't easy for the user to make lots of different accounts. In general, you probably can't stop this entirely, but you can make it enough trouble that most won't do it by making it require enough steps (including some sort of captcha so it can't be automated).
SSL will protect client/server communications, but won't do anything to stop the client from doing things you don't want them to do.
“Encryption” does not make any sense here as you have already been told (because the value that would be encrypted client-side could be manipulated before you encrypt it), and SSL does of course not solve this problem either.
Send the access token of the user to the server instead. And then either make a request for user data with it (/me), or debug it – then you will know that the request is genuine, because a user can not “fake” an access token for another user.
Considering that there is no authentication an HTTP fingerprint can be used to check if requests with different userId come from the same user.
Fingerprint will be create from HTTP request data like:
-user agent
-language
-IP
-charset
and other data present in the http request.
I want to pass an email address as a parameter in a URL string but hide it. The URL string is constructed in a Java routine and the jsp page receiving the request will pass the string to a server side java routine to decode it. Someone must have already written this code but I cannot find it - probably not asking the right question. Thanks. Fred
If you're including the email in the URL you cannot hide it, but you can encrypt it.
If encryption doesn't rock your world, and you simply want to obscure the email address, you could obfuscate it.
The other way to submit it with out it being so obvious would be to use POST to send the data to the jsp page rather than using Querystring.
Typically, users have a session with data stored on the server. The e-mail address would be stored in the session object, on the server. The client supplies its session ID in a cookie or in the URL. This way, you can pass information to the next page without putting it in the URL.
If you don't want to deal with this via a session, or you're passing this string between servers, you have two options. Either Hash the email, or Base64 encode it. If you're worried about anyone other than you ever (or the user) finding the actual email, don't use Base64. However, if that's not a concern, then base64 is the easiest and fastest way to include an email address the doesn't look like an email address.
If, however, you're worried about the information leaking in any way, use MD5 or SHA hashes of the email. To speed the lookup in the DB, you may want to pre-compute the hashed version of the email and store it in an additional column in the table.
I'd recommend SHA over MD5, though for this lightweight usage, I doubt the flaws in MD5 will affect you.
Use hiddden form fields.
<input type="hidden" ...>
Hidden form fields come into handy when you dont want them to be exposed when transferring from jsp page to servlet and then to a java bean.
This question already has answers here:
Handling passwords used for auth in source code
(7 answers)
Closed 7 years ago.
I'm writing a Java class that connects to a server and reads messages in a given queue.
I would like to protect the username and password, which, right now, appear as plain text in the source code.
What I'm wondering, is, what is a good way to do this? If I encrypt the username and password in a text file, won't I need to store the key, in plain text, in any source code that accesses this file? And then anyone else who decides to use my class will be able to gain access to these fields.
There is no prompt where someone can enter the key, either, as this class will autonomously be used by the system.
EDIT: this will become a java lib file. But those can easily be decompiled and thus are basically the original class files anyway, right? And the people this is being protected from are fellow developers of other systems who will gain access to this lib file.
My End Goal: is to have the username and password strings not appear as plain text anywhere, and for them to be as difficult as possible to crack.
It is not possible to do this. Even if you encrypt the login/password and store it somewhere (may it be your class or an external file) you'd still need to save the encryption key somewhere in plain text. This is actually just marginally better than saving username/password in plain text, in fact I would avoid doing so as it creates a false sense of security.
So I'd suggest that your class takes username/password as a parameter and that the system which is using your class will have to care about protecting the credentials. It could do so by asking an end user to enter the credentials or store them into an external file which is only readable to the operating system user that your process is running as.
Edit: You might also think about using mechanisms such as OAuth which use tokens instead of passwords. Tokens have a limited life time and are tied to a certain purpose so they pose a good alternative to access credentials. So your end users could get an access token with their,say, Windows credentials, which is then used inside your class to call the protected service.
This is a classic authentication issue, except that here, Eve can wear Bob's skin like a suit. Is that stretching the metaphor? I'm not sure.
The short answer is that there is no true answer, because what you want is something that basically violates information theory, in that anything transmittable is copyable and thus anything accessible can be viewed as no-longer-unique. Even if you had a magic box, they could just yank out the magic box with some serious JVM hacking.
The long answer is that there are a few solutions that are almost pretty okay, by making it really quite darn hard. I suggest you read the article linked, acquaint yourself with the ideas behind SRP, the vulnerabilities the spec entails, and try to figure out how to get the right to use and implement it. The problem is still there though. It's that you want a system that ensures Bob can never become a flesh-chariot, or fall to the dark side.
Fundamentally, you're breaking the tenth law. I agree with Kork, there's no solution that really does what you want, because you're trying to solve a social problem with a technical feat, one that is quite nearly provably impossible.
There are a few ways of handling this problem. The challenge as you've noted is associating an account with this automated process. So, here are some of the possibilities (from least secure to more secure):
Encrypt the username and password with a calculated key.
The calculated key is based on something both the client and the server can infer (like machine name and IP address)
Associate an authentication token with the client (OAuth style).
The token is negotiated by a one time user interaction to set up the client
The negotiated token is used for all future requests
The negotiated token is only valid for that client on that machine using that user account (server uses socket info to determine the match)
Use multiple forms of authentication
OAuth style token
Calculated token based on time + secondary id (requires clients and servers to be synched to the same time server)
It is important to note that your security measures should be more restrictive than it is worth to crack. In short, if all the potential bad guy is only going to be able to get your food preferences of the day you might not need to be as vigilent as protecting something more high profile like a bank account. User names and paswords are not the only means of authentication.
It's not clear which code has to know the user name & password. Are these credentials just for the queue being read? If so, only the server code would need to know them. In that case, you could store them in a server file whose permissions allow only the server code to read them. The file permissions would then be enforced by the server operating system, which presuambly is much better at security than most programmers will ever be.
I know this question is long since abandoned, but I want to point out that of course you can do this by requiring typed credentials at runtime but only storing a hash of the password. Of course, it needs to be a really good hash. Use a standard one, don't make up your own. The whole point of a hash is that even if you plain text the hashed result, no one else will be able to come up with a string that yields that hash, even if they know how the hash is computed.
Of course users can try a brute force attack, and since they know the result they want they can run it fast, so you need to use a highly secure password.
when people register to my website i don't want to send them a verification e-mail, i just want to check if that e-mail exists. is there a way to do such a thing ?
using apache-tomcat and java as my main programming language.
thanks a lot!
No. There is no way to tell if an email address points to a valid destination. You can check basic syntax, and that the domain has a record in DNS, but that's all.
You can at highest use regex to check if the address is syntactically valid and/or looking up the MX records if the domain is valid, but this still does not guarantee that the email address is legitimate and belongs to the registrant in question. There is really no more reliable way than sending a verification email and waiting for confirmation in a short time-span.
contrary to some of the uneducated answers you can TRY and connect to an MX server and use the VRFY command to see if the sever supports it. Here is a website that will do this for you as an example. If you look at its exchange with the MX server it actually does try and send an email but does a RESET before actually sending it. Testing it with my email address works but I don't get an email. So yes you CAN do what everyone else is saying you can't do. Use an address you know works for your domain, then use one that you don't isn't supported. You will get a 550 on the last RCTP TO command. That is how you know it doesn't exist.
I just wanted to weigh in and say that despite your reluctance to do so, PLEASE send an email and force the user to confirm that they have control of it before allowing that email address to be used in association with an account on your site. Why? Because not doing that, for any reason, means that users can sign up for accounts using email addresses that aren't theirs. They might do so accidentally, or they might do so very much on purpose (e.g., signing others up for accounts for any number of reasons); that's just not kosher, and websites that allow it are open to being reported to their ISPs.
(I say this as the owner of a Gmail account which, at least two to three times a month, is signed up for an account at some website that doesn't force users to confirm their email addresses in this manner. It's irritating, and it puts the onus on me to get the account removed from the offending website. I've now taken to recovering any passwords I can, logging into the account, and then changing the email address to "UNKNOWN#gmail.com" or something like that... it's sorta fun, but I doubt you want this to happen on your website.)
This has been answered already in previous questions here. Without a verification email, the best you can do is look at the email address and look if it seems valid. You can also check things such as the domain, to see if it exists and has MX records. Anyway, see https://stackoverflow.com/questions/3232/how-far-should-one-take-e-mail-address-validation and Using a regular expression to validate an email address
If you just want to verify that it LOOKs like a valid email address, there are many sample Regex's that will verify that. If you want to verify the user has control of the email address, you'll need to send something to it and craft a unique response to verify it.
i guess this is what you are looking for
http://www.strikeiron.com/Catalog/ProductDetail.aspx?pv=5.0.0&pn=Email+Verification
You can use the openid service to check for valids email addresses as stackoverflow does.
http://openid.net/
Email Verification services are very helpful in validating email address. Most of them performs 6 levels of verification like syntax validation, Domain MX record Check, Role based Account detection, Disposable email address (DEA) detection, HoneyPot/Spam track detection and deep level SMTP verification.
Most of them offers API integration, so, you can directly validate email addresses from your application.