We have a really small setup but for the sake of keeping everything centralized we have a domain.
Occasionally managers will need to send email out as somebody else if they are not in the office, is it possible to add a secondary password or a master password to everyone's account through a group policy? That way if needed we could logon as that user and send out an email. Obviously it seems a little unusual but the password would only really be for one or two mangers. Not everybody.
I was thinking just giving passwords out to everyone and keeping track of them and not allowing them to change them, but seems bad practice.
This is not possible. You can configure Exchange (if you're using that) to allow people to send mail as or on behalf of other users.
Related
I've an Azure AD B2C setup that no matter which email I insert in forgot password email's field it will send the verification code email to that email.
Even if the email doesn't exists in the Users list.
Is this the default behavior?
This is the link I have for recover password
Is there any missing property in the url that force check if the email exists in User list ?
I can confirm the behavior but I couldn't find any reference on why exactly it works that way. Like many things in security, I'm pretty sure it's a design trade-off.
Some services (e.g. Evernote) do the same, i.e. they send a password reset email no matter if the address is registered with them or not.
On the upside, this is an early alert for the user that someone is trying to get access their (nonexistent) account, so a phishing attempt coming from a different website is likely.
The problem is that the user gets an unsolicited email message, and if somebody wants to annoy him/her, all it has to do is to send multiple reset password requests. The user is helpless, there's nothing he can do to stop the emails. So I presume the service mitigates this by limiting the number of reset password requests to a reasonable amount (say max 10/hour, but no more than 3 in any 5 minutes).
Other services (e.g. Dropbox) take the other approach and only send email messages to addresses registered with their service.
this prevents the "email bomb" issue
on the other hand, it doesn't alert the user about the login attempt
Like you, I would argue that the latter approach is better, as the only benefit I can see in the former one is the "early warning" issued to a user that's not even registered with your service. Also, understanding the early warning requires some user sophistication. But obviously Microsoft went the other way.
There's a Password Reset item in the Users blade, but the only options are None and All. Interestingly, the tooltip on this option mentions an nonexistent "Selected" option, so some more fine-grained settings may appear here in the future.
If you want to exists if the users exist before sending messages then you have to edit the SendCode Action . So it will only send verification code when user exists in B2C side.
Below is the very good link which can help you with that.
https://github.com/azure-ad-b2c/samples/tree/master/policies/pwd-reset-email-exists
It is by design. And it will try to send out the verification code without validating whether email exists or not.
By considering security measures this is how it should work.
I need to allow a user of my App to email themselves when an even occurs. I am not sure how to do this.
My first idea is to create a dummy gmail account, and have my App sign-in and send from there via java code. This means hardcoding the password BUT as account not used for anything other than one way emailing - it does not seem to be a problem.
However, I understand that google is pretty proactive about security and if my App (which is global) tries to log into same account in several different countries during a 24 hour period - it will block the email.
I have seen the "delegate" functionality, but that would mean that each user needs their own gmail account which is not practical.
Is there a way to force gmail to allow the sign-ins to happen from wherever?
Or is there a better approach to this problem?
probably not a good idea to have your app to mail from a private account, if I understand you correctly. Best to use email service like http://expresspigeon.com or http://sendgrid.com and simply send a transactional email from your app account. In other words, use an ESP.
The safest would be to ask the user for all the configuration information necessary to access their email server as themself, then send the email as themself to themself. You can use JavaMail to send the message, but you'll need to ask for all the configuration information that any other email application would ask for in order to configure access to their mail server.
There may also be Android-specific ways to do this using the default email application.
I have in my web application a role called "Administrator". Users who have this role should be able to modify the information about the registered users.
I am thinking about displaying a table with the user details such as e-mail, username, and be able to change them but I don't know what should I do if a users comes to the office physically, goes to an admin and asks for a password change (yes they can do that). Should the admin just press a reset button over the row and tell the user to check his e-mail when he arrives home and proceed with the recovery? (reset link for example) Or should the administrator reset the user's password and give him his new password in that very moment? The second approach is preferable as I was asked to do that...
I know that the admin shouldn't be able to see the original password as it should be hashed and unknown.
What are your thoughts about this? How would you implement this functionality? Thanks for your help.
There is no one perfect answer for this question. The question of workflow will always be dependent on the specific use-cases of an application and will depend on the context it is built in.
That being said, you are right about one thing - it is horrible, and I do mean horrible, security breach to let an Admin or any other user view a clear text password for someone else. So that's definitely off the table.
In your case, it seems giving the admin the right to change someone's password is the way to go. If you're worried about how it looks, don't be. Google Apps allows domain administrators to change the password for any email account under that domain.
Finally, I would suggest a small additional safety measure. When an Admin changes another user's password, store the old encrypted password in a column, don't delete it. When the admin set's the new password, shoot out an email to the user saying "Your password was changed by the Administrator, if you did not request for this, please click here". When they click on the link in the email, simply overwrite the new password with their old one.
That way in case an Admin is changing passwords without the user requesting it, you have a recourse for the user and the logs will keep you informed of how many time an admin has had a password reset revoked by the user.
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
I have a business requirement that calls for an end user to be able to login to an e-commerce system with a one-time use password, purchase a course, and then never be able to login again. At the moment the company that is allowing their employees, my client's students, is going to generate that password for them and send me a list of the passwords they are generating.
I do not like the concept but I have yet to come up with a better one that will work for all parties. If something happens mid-purchase they have to go back to the company to get new login credentials.
The ability to purchase a course cannot be open to the public, it has to be through the e-commerce portal, and for the moment there is only one company participating but there will be more in the future. I am seeing this as a total maintenance nightmare.
My question is has anyone run across this before, if you wouldn't mind sharing tell me how you solved it, or point me in a direction that will give me some insight. I have googled the concept to death and have not come up with any bright ideas.
You can't resolve the "problem during purchase" issue yourself - They need to modify their service so that the password is destroyed when the transaction completes.
No matter what you do with regards to the password, once the user is logged in, the password is disabled on their servers. After that, you have no control.
They should either:
Cancel password on transaction completion
Provide you with an API/Web service to allow you to request a new key.
I have the answer for this one and document it here for my own personal OCD completion purposes. I created a login form that allows for a two part key; username is based on company name plus internal company ID(not a guid), paired with a password that is cryptic key, ex: #SCD6-, plus employee id generated by the company. The rub is I don't know what the employee ID is, and only use it because it should be unique although it doesn't matter if it is not, once the user logs in once completes the only marginally secure process then checks out the login is invalid and can never be used again, unless manually unlocked (in case of a duplicate employeeID at some time in the future, which is unlikely). The username and key is emailed to the employees of the target company, which is generated by the target company.If I do have the employeeID in the system which is 50/50 then I can pre-fill the forms out.
The only thing this lock protects is a process and not secure information so I am not too worried about security and it's only real purpose is to keep John Q, from stumbling onto the process and paying money that my client would need to refund later. If it were a secure data process I would not use this method.