I'm building a system, where its registered users are able to send emails automatically. I came across 2 solutions to achieve this,
By getting the username and password of GMAIL accounts and sending mails using nodemailer.
By using Google Oauth, to let the users give access to my app to send mails on their behalf(Without sharing their mail credentials).
The first method works as a piece of cake, but the second option sounds a bit more professional and safe. I figured out how to send mail using a single acc. to other people. But couldn't find a possible solution, to send emails from the user's mail. (As it requires refresh token to send them)
I came here looking up for a possible solution that helps me solve this issue.Thanks in advance!
Go with google OAuth or if using first one use bcrypt salt or some type of hashing to secure password.
I would suggest you to go for second option. There is a good and very important reason to do so. You need to have a good and secure DB to save this information which could be an overhead for you.
Hashing the password and saving it to the DB won't help you. As you can never get the actual password from the hashed one and you can't send the hashed password to the gmail account. So, you can't do that.
Second option is a better way in every term, you just need to have a refresh token and that won't be a big deal. You can get it nodemailer transport layer can help you to get it.
I am attaching this link where you can easily replicate the steps to get it done.
Related
I have just signed up for SendGrid and have been able to successfully email but I was wondering if it is possible to send emails with no authentication? At the moment I have only been able to send using authentication.
Thankyou in advance for your response!
Why do you want to send without authentication?
Imagine that from SendGrid's perspective, how are they going to know that it is you sending email (and hence bill you for it) and how are they going to prevent just anybody connecting and bulk sending whatever they want!
This is known as an Open SMTP Relay and is generally considered a very bad thing™ ;)
The good thing though, is that it is very difficult to find an application that doesn't support SMTP authentication. Whatever you are using will have a setting to configure auth, and once its set up you can likely forget all about it being there.
However, if you can give an idea of your use case, we can probably help you figure out a better way of achieving your goal...
I'm thinking about a sign-up-with-mobile number system whereby someone can register with a mobile number and get a SMS to verify that they exist... at which point I'd like to have them automatically logged in without a password... (the SMS is basically a password)
This is patterned on the Lyft app sign-up, which doesn't ask for a username/password/etc.
But for the life of me, I can't figure out how to do this.
I'm totally fine with a server only Meteor.method which responds with something "secure" but I don't know what that would be now.
The only thing I can think of would be to set the password on the User and then transmit it to the client and run a login (which seems insecure to me).
I have read through this great article
https://meteorhacks.com/extending-meteor-accounts.html
and it's a good option, but I don't know of a strategy for that which wouldn't bypass security too
(at some point the server has to communicate securely back to the client...)
Recommendations?
I made a package that might help you, Meteor accounts phone, which do login based on sms mobile number verification https://github.com/okland/accounts-phone/ Enjoy!
Before I begin, my reason for not using OAuth is I believe it is not really something we should be using on this project, we're targeting a platform that will be packaged and resold to companies, which connect to their own set of uses that we really don't want to have accounts that we are not %100 in control of, we don't want it to be a shared-login with other services, and we don't want to force people into getting a google/yahoo/openID/aol/facebook/blogger/wordpress/whatever account.
Now then, What I would like is the best way to let users re-set a password.
I hate the concept of secret-questions: What school did you goto? Well, lets check your facebook page. What was your first-grade teacher? Lets just ask them casually.
I hate using one-time-passwords via email: Since when is email secure? Your boss reads it. Your sending out spam emails to me every day. It went into your junk-bin. It's not sent encrypted.
I don't want to use a password to reset a password either. This just doesn't make sense.
I'm really out of ideas here for the best way to do this, so I figure I would ask the community.
Your problem is that you need to outsource trust. If the user forgets their password, you no longer have a direct way to trust them, so you have to use an outside source to reestablish your relationship.
If you think email is insecure (which it is, actually), you could try telephone. Give them a call with the temporary password. Or a fax. Or snail mail, or an SMS, etc.
This is as secure as the phone lines/postal carriers over which the reset travels, and in most areas, telephone intercepts or tampering with the mail is strictly punished by the law.
If that's no good, consider issuing users an OTP token, or smartcard, or something.
Barring being able to vet the person in person, I think you've listed all the reasonable options I've seen. In my opinion the one-time-password via email is the superior option as people tend to at least want to keep their email private. I personally hate secret questions - too big of a chance of the answers being public (see Sarah Palin email incident). If you are going to do secret questions, at least let the user choose their own questions.
I think this requires a difficult implementation but sending new password to user's mobile phone as a text message may be an alternative solution. Mobile phones are much more secure than personal inbox.
Then, users are asked to enter their mobile phone numbers. Users that doesn't want that functionality are provided new passwords by email.
Make users select a secret image (or images). Or make user upload their own image.
This works better than secret questions. Secret questions have two common problems:
user gives an answer that can be easily obtained by others.
user knows about first problem and instead of a real answer gives a random answer, later on forgetting themselves what it was.
By making user to select secret image(s) or better yet upload their own images. It'll be easier for user to recall it later when recovering the password, since it's easier to make visual associations.
When recovering the password present user with several choices to pick the right image.
So you actually want the user to prove that he is who he claims he is, without revealing information about himself (assuming you can get ANY information with social hacking)
There are 3 ways for authentication: Something you are (biometrics), Something you have (dongle for example) and Something you know (password,response...). 2 or 3-way authentication is much more secure than 1-way.
Password reset/recovery, by definition reduces the security of the authentication procedure, because its now not A, but (A or B). (A= password, B=recover-password)
Therefore, even if your authentication procedure is 1-way (password), your recovery processes should be a 2-way authentication.
Let's see what are your options for the password recovery process:
Something you are (SysAdmin that recognize you - usually not good for 5000 workers organization, Voice-print - too expensive to implement, ...)
Something you have (e-mail account, phone number, ...)
Something you know (personal details)
Notice that corporate-ID tag with picture is a 2-way authentication (both something you are and something you have).
I think the best procedure is for the employee to physically go to the IT department, show his picture ID, and ask for a password reset.
If this is infeasible (too far - a remote branch for example), try to use a deligator who is recognized and can be trusted over the phone, so the employee will have to show the ID-tag to a local deligator.
If you can't use the 'Something you are' - you're left with something you have (e-mail, phone-number,your own PC) and something you know (personal details...). You can't escape it.
Is it better (more convenient or secure) to provide users with a lost username or password via direct message on Twitter rather than via email?
You don't supply lost passwords at all (mostly because you can't, because if you're doing it right you don't store passwords in plain text anyway).
You facilitate a reset-feature that allows the user to, with the help of for example a secret question or simply an activation link via email, change their password.
I really don't want sites throwing my username and password over Twitter.
No thank you!
It is as secure as sending it over email. If you generate a new password and then send it to the user via dm only the user can read it. And yes the user can access twitter in an unsecure way over an not encrypted connection. But you can't assure that somebody uses an encrypted connection to access his mail either.
In fact it could be more secure because you know that only twitter admins can intercept the message and no admin reading the mails from his users
Security aside, there's also the significant flaw that you can't send password reset information, password reminders, or anything else to your user via direct message if he's not following you on twitter. Unless your site is itself a twitter client, then the odds are pretty good that a substantial fraction of your potential users won't be particularly interested in following you and are likely to resent being told that they must follow you (or at least follow/change password/unfollow) if they want to use your site.
Update: I forgot to mention... If you want to tie your user authentication functionality to twitter, then why not just use Twitter OAuth instead of maintaining your own password store at all? It works quite well (barring the fail whale), is very quick and easy for the users, and doesn't place any requirements on who they follow or don't follow.
Start by reading this post: What is the best “forgot my password” method?
This will get you started in the right direction.
I want my password sent by UPS, FedEx, or USPS when I forget them.
Punish the user.
Bad user.
Enough people have pointed out that you shouldn't be storing passwords in plain text anyway, so I won't repeat that.
But if you're sending a one-time-use password-reset link as a Twitter DM, then you have to take into account that the user might receive that message on their mobile phone.
Then you'll have to make sure whatever that link points to is set up to display correctly on mobile phone web browsers.
Then you'll wish you just stuck with email.
Secure your passwords and don't send anything by email or twitter. Lookup MD5 and other algorithm to do this.
Wikipedia says:
In cryptography, MD5 (Message-Digest
algorithm 5) is a widely used
cryptographic hash function with a
128-bit hash value. As an Internet
standard (RFC 1321), MD5 has been
employed in a wide variety of security
applications, and is also commonly
used to check the integrity of files.
I hate it when I see a website storing my password without encryption... and if the website started sending me my password via twitter I'd break something.
Instead of sending passwords verbatim over any insecure channel, send a nonce instead. Such as: a one-time URL the user clicks, verifies personal info, then is forced to choose a new password.
This way, if the message is intercepted, no damage can be done without also hacking the personal questions.
What is your opinion on sending the username and password to their email address when they register on our website..this way if they forget the password in the future, they can look it up in their email...also we wont have to implent the forget/reset password scenario (we are close to release)..
is this approach safe enough?
My second question is that basically on our site, the user fills out certain forms and enter some information like their name, address, phone number, income information and such personal information..at the end, when they submit the application, we are thinking of emailing them a summary of all this information like their name, address etc so that they have it for their records..
is this ok..safe enough..what are the concerns
Never send a password or other sensitive information in the clear. That includes e-mail. You should also be storing as little of this as possible in a recoverable format. Unencrypted communication, especially e-mail, is easily tampered with, and you don't want the wrong people getting at passwords.
If possible:
Store your passwords in a salted hash, so the original text is unrecoverable, and thus unbreakable by anything short of a brute force attack. If the user forgets his/her password, make them reset it and send a temporary password (which they are required to change upon login) or a confirmation link (which, again, prompts for a new password) via e-mail.
Never send anything sensitive via e-mail; if the user needs information, make them go to your site to get it. You are using HTTPS, right?
People often share passwords across sites. So you should assume the same password works for the customer's online banking, and you should never send it by e-mail or provide a way for (someone pretending to be) the customer to retrieve it.
It's fine to send them a confirmation e-mail with their username - this is useful.
Remember, if you e-mail them their password they're likely to forget about that e-mail, or just delete it. So you need another password reset mechanism anyway.
The best way to handle the "forgotten password" case is for the user to request you to e-mail the user a link; when they click the link you allow them to type in a new password.
Regarding personal information (address, income etc): why would anyone want this mailed to them? They already know it! You're just sending private data unencrypted over the internet for no reason.
My rule of thumb would be - if you're OK writing it on a postcard and sending it through the mail, then it's OK for standard Email. I don't think income information would fall in that category for most people.
As for passwords, if they can't remember them in the first place, they won't be able to find the Email you sent them with the password in it, and it's an admission of storing it in the clear. I would avoid it and give them the means to reset - they will need that anyway.
The concern is definitely in the sending of the email with the password. If it is not properly encrypted, someone could potentially sniff the packets from the email being sent and recover the password. Also, the person could potentially have a hijacked email account. If it's not a big deal if someone steals the password then you may not have to worry, but otherwise I would NOT send any unencrypted passwords via email.
Edit: To address your second question, I wouldn't even email that. I would instead send a link so that they can easily see their profile/information when they log in.
I tell people to think of email like a postcard -- an employee of any company that handles it between the sender and the recipient can read it.
I agree with the top answer and have this to add: every time I receive a signup confirmation email that contains my password I delete the email and strongly consider never using that web service again. To me, it indicates a lack of security & privacy consciousness.
When you are sending any information via email, it won't be secure. There are too many ways someone can get it. It would be child's play for a skilled hacker looking to steal your information.
Refrain from sending any personal information like passwords and income information via email as it can become VERY EMBARRASSING for you and your organization if such information was leaked or stolen. Think about security seriously. It just takes that one incident for all the bricks to fall.
As for password retrieval, thoroughly read Forgot Password Best Practices.
The bottom line is that an application
following best practices should allow
a user to reset his own password.
Personal security questions should be
used. The application should not send
email, display passwords, nor set any
temporary passwords.
EDIT: Updated Link...
Most company simply do not include Username password combination due to the security of the external email client. Any numbers of users could brute force or guess the password to the email account of another users which would allow the hacker to view the email of your site. Then the hacker could wreak havoc on your site as well
I'd say providing a forgotten password function will still be vital as not everybody will be guaranteed to keep all there emails (or even be able find them later on)...
I have three rules concerning passwords:
Don’t store passwords in plain text in the database
Why should people trust you with that kind of information? You may only have good intentions, but big companies have failed before, so you're at risk too.
Don’t use password reminders
Password reminders are not worth it. They are easy to guess from people in your entourage and you often forget them. There are better ways to reset a password.
Always offer to send a new password by email
This is the most secure way of retrieving passwords. You should force the user to change the password once logged in with the new password.
As mentioned in comments, you might want to look at OpenID. The most secure way to manage passwords is to eliminate them.
I build an Web Application to send sensitive information by email. It's not UI perfect but it's really secure and working very fine.
There an outlook plugin, API to connect external website and the WebSite.
The concept is the message received in your mailbox are not in clear text. It's an HTML email with a link. You need to click the link to access the content of the email. When it's access one time, the message are destroy.
The message are stock in a crypted database on our side. You can configure a password that are know only by the two part to open the message online, or receive an password (Random 6 number) by SMS.
It's very simple to implement by API.
There is a sample
// https://www.secure-exchanges.com/API.aspx
List<string> files = new List<string>();
files.Add(originalFilePath);
string input = $"{body}";
string inputSubject = $"Your {subject}";
SendMessageAnswer answer = MessageHelper.EncryptMessage(new EncryptMessageArgs(GlobalSettings.bindingSecure, GlobalSettings.serial, GlobalSettings.ApiUser, GlobalSettings.ApiPassword, input, inputSubject + " - to open", recipient1, "", password, null, SecureExchangesSDK.SecureExchanges.SendMethodEnum.onlyEmail, false, true, true, "fr-CA", 1, 5)
{
FilesPath = files
});
if (answer == null || answer.Status != 200)
{
throw new Exception($"Impossible d'envoyé un message : {methodName}");
}