I am using Outlook 2010 desktop application.
I want to password protect the email sending option so that if anyone tries to send an email using my email account, a password will be prompted (popup) to verify whether it's me.
I heard from some friends something like that I can create a macro,adding a module on my outlook, filter, maybe code it using VB langage or others... and when I leave my desk I must only active this filter or something like that and then nobody could send an email using my email account but I don't know exactly how can I do it... Anybody has an idea please ?
You can use the MailItem.Send event. When this event occurs, you can display a dialog that prompts for your password.
Here are the details for this event.
https://msdn.microsoft.com/en-us/library/office/ff865379.aspx
If the password is incorrect, you set Cancel=True to prevent the item from sending. I recommend implementing a timer so that your code doesn't invoke this password prompt while you are actively your system.
I'm assuming you are developer and can take it from here.
Related
When a user tries to log in but fails with a bad password and then clicks the forgot password link, they are directed to a URL containing their PII email.
The hint is not injected until the link is clicked, so it can probably be fudged with some custom JS, but we would like to use configuration rather than customisation..
e.g.
https://b2ctenant.b2clogin.com/b2ctenant.onmicrosoft.com/B2C_1A_customflow/api/CombinedSigninAndSignup/forgotPassword?csrf_token=xxxx&tx=StateProperties=xxxx&p=B2C_1A_customflow&hint=blablablah#example.com
This PII has potential to be captured/logged/etc, which we would really like to avoid.
So, can we turn that off?
Yes, we understand this is a convenience/quality-of-life feature to help clients, but revealing their PII seems a poor trade-off.
If you initiate Password Reset by clicking on the "Forgot your password?" link at the sign-in page, clicking this link doesn't automatically trigger a password reset user flow. Instead, the error code AADB2C90118 is returned to your application. Your application needs to handle this error code by running a specific user flow that resets the password. You should be able to handle the URL and forgot password from the application.
The Azure AD B2C guidelines for using custom JS (https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-flow-javascript-overview#guidelines-for-using-javascript) direct prohibit binding the click event on anchors/links, but we can use the mousedown event.
With that, we can use a JS snippet as below to clear the signInName field, and so prevent the link from containing the hint parameter:
$("#forgotPassword").mousedown(function () {
$("#signInName").val("");
});
This addresses the issue with customisation, so now we wait to see if we can replace it with an official configuration option.
Usually, when you sign up for an account on a website or post something to Craigslist, the website will send you an email and your account won't be active until you click the link in your email.
I know this is done to confirm that you are a person and prevent robots from spamming the site, but I don't understand what is going on server side.
Does the site save your information in a temporary database? Does the email link they send you secretly contain all the information needed to start your account?
Very curious if there are different methods for doing this and what the pros/cons are?
The server, well. It saves the user information, generates a pseudo-random string (generally a 32, 64 or even 256 byte token), which "identifies" you as you.
In the email, it sends you, it will and an anchor (and as you click it), it will recover that token and make your account active.
An example using an anchor + GET param:
http://example.com?token=acbd18db4cc2f85cedef654fccc4a4d8
md5('foo') => acbd18db4cc2f85cedef654fccc4a4d8
For the 'pseudo-random', any criteria is available, since the id your were given in the database, to some random crypto utils.
i guess the link that you get in the email contains a unique string for the new user that is not confirmed, so when you open the link the server can select which user confirmed the email.
We have a password reset web application. The application sends out an confirmation code to an alternative e-mail. My manager believes it is not a good idea to include a link to the page were you have to enter the code.
I see his argument. However, the helpdesk has been overwhelmed with users who are confused about the process. I'm assuming this is because many our users browse using only one tab/window and navigate out of our web application to check their e-mail for the confirmation code.
My question: How should we approach this issue? I would like to alleviate helpdesk and, in turn, make the process pain free for our users. Any suggestions?
Clarification
He believes that we are doing the user a disservice by training them to click links from a sender that cannot be verified (in this case, it's an automatic message with a "no-reply" address). This, would in turn, make users more susceptible to phishing attempts which we've had a lot of issues with in our organization.
I think sending links is the standard way of doing it. If a customer is really worried about the integrity of this email account, he better gets that sorted out first.
Essentially you don't gain extra security by not sending the link, but you gain a lot of comfort. Just do it like everyone else - put it in there (time limited).
The only thing on the top of mind would be the option to have a unique identifier in the e-mail's subject an have the customers reply to that mail.
Then an automated script checks 'password-forgotten#mycompany.de' for emails with the subject 'Re: Forgot your password? [UNIQUEID]'. The script would then mail them their new password.
Since most users won't modify the subject when hitting "Reply To" and won't do a "Compose new mail" and enter the recipient address manually, chances are big, incoming mails to "password-forgotten" will have that UNIQUEID in the subject.
Plus helpdesk would only have help those that actually modify the email's "Subject". ;-)
There are security considerations, though. Maybe your manager might argue, that anyone might send a forged "Forgor your password" mail and set the "Reply-To" header to the attacker's address. The processing script has to intercept these attempts of forgery...
I see no reason why the link shouldn't be included, especially if the code is something like a hash because the chances of somebody cracking that are slim to none.
You could however, add an extra protection to the page where the code is being inserted and limit the number of tries to something like 3. For even more protection, send the email address to that page as well, and allow 3 tries per email address instead of 3 tries / IP, which can be easily bypassed.
On a standard web signup form, users are required to have a unique email for the site.
if the email is already in use, a new user cannot be created with that email - but this opens op for exploiting this to find out, what emails are members of the site (at least check if a specific email is in use).
Making sure a bot cannot mass-query is fairly straightforward - but is there a way to avoid it entirely?
The best thing I can come up with is letting the user create process fail with an unknown error and shooting an email to the address in the background, explaining password reset procedures.
Am I missing a better option?
Update:
I want to avoid taking the new user out of the registration process for the 99.9% of the time, when the email is actually unique. So halting the registration process to wait for the user to click a link in an email is not a perfect solution, although maybe viable in some use cases.
Let the registration continue as normal, but in the confirmation email you should say:
"You allready have an accout bla, click here to cancel this registration, or continue with new registration and delete your current account"
That way, the spammers never know the better, and its very user friendly.
You could print on the web-page something along this:
An email is sent to you to verify the email address. Check your mail and click the included (shared-secret) link.
I.e. you probably have to verify the users email anyway, s.t. you can do it at this location of dialog ...
Many sites send a mail to the specified email address containing a randomly generated verification code and only accept the user registration once the user has confirmed they were able to read that mail and obtain the verification code. Usually the mail contains an URL that the user can simply click to confirm.
If you do that, all you need to do is make the confirmation email instead tell the user that they've already registered and explain the password reset procedure.
Whatever web development framework probably has a package that handles confirmation mails.
Note that you have to think about the case where a user had an email address and used it to register to your site, then they vanished without changing the address and stopped using the address, and another user now has the address and wants to register. There's no easy answer here.
ADDED: You add that you don't want a confirmation email so that the registration proceeds immediately. This requirement is contradictory with unique email addresses, because you don't know that the email address supplied by the user is legitimate until it's been confirmed, and there's no point in enforcing the uniqueness of a user-chosen string that just happens to be formatted like an email address (if you want a unique user name, it doesn't need to be formatted like an email address).
If you want to keep instant registration, you'll have to treat email addresses as just an untrusted text field until confirmed. That means that every action that requires your site to send a mail must bomb out if the user hasn't confirm his email address. The confirmation process remains pretty much the same, but now, if the address is a duplicate, the user must either be given the option to merge the two accounts (which sound difficult), or told that he must close one of the two accounts or change the email address associated with one of the two accounts.
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}");
}