To secure AWS account it is good to have virtual MFA device, such as Google Authenticator.
Usually, you can just take a picture of the QR code, and use it on as many devices as you want (as here suggested https://webapps.stackexchange.com/a/66666/188445, sorry, couldn't comment on that answer, don't have the reputation).
However, on AWS it asks two codes to confirm, that makes me think it is device specific. Is any way to make an AWS MFA on two devices or use backup if lose my phone?
First, I'll be that guy and say - don't backup your MFA key. If you lose your device, just jump through the steps of resetting it by contacting support.
While it doesn't necessarily defeat the purpose of increasing the security, and while it's also probably not likely that someone will attempt to steal your key, I don't think you're doing yourself any favors, security-wise.
But that's not what you're asking about.
When you say "on AWS it asks two codes to confirm, that makes me think it is device specific," I'm not sure I follow. Yes, it's device specific, in that you need the specific device that either scanned the QR code, or entered the key in, in order to auth via MFA.
But just because there are two fields, it doesn't mean that there are two different QR codes or MFA keys you need - you just need the one they show you.
After you set up your authenticator, you enter the first code you see into the first field, then wait for that to cycle out, then enter the next one into the second field. Asking for two codes just ensures that your authenticator is working correctly. It's not any different that other services that use an authenticator as MFA - some only ask for the first code that appears, some ask for two. (Personally I think two is better.)
Related
I've encountered several fairly serious problems in my efforts to develop a speech-to-text application. Some of them (I hope) may just be my lack of experience/common-sense/in-depth-reading/etc. Here's the list:
Long (>60 sec) transcriptions -- Forces me to use a GS bucket to first upload the soundfile to the bucket. Trouble is:
a. I have to run the "gcloud auth login" on each machine I need to run on. I have well over 50 machines. This appears to be a purely manual operation, as you have to copy a long URL to your browser, hit enter, click on the right account, accept the permissions, then hand-copy and paste the key presented back into the gcloud prompt, and hit enter there. While it does appear to be presistent to some degree, it is subject to one interesting constraint: only 51 machines (maybe 50, I got tired trying to count) are allowed. And the earliest logged-in machine is un-loggedin to make room for the new login. This was very odious. All this hassle is purely for using the buckets. A shorter transcription will not use GS, and complete without complaint. Really!!!! Is there no better way? Do we have to use gcloud auth login? Manually???? The number of servers we can use with GoogleStorage????
Another google storage issue: transcription requires the bucket to be "public". We are pretty worried about security, and the privacy of our customers, whose recordings will be in the uploaded bucket, even if only there briefly.
The transcription app offers transcriptions in multiple languages, but the "phone_call" model is fixed to en_US, and seems to ignore the language setting. If I change the request to es_US, and supply a spanish recording, it behaves the same. (But everything works OK in the 'command_and_search' model). This seems to be in evolution, any idea when/if they will carry the multi-language features over to the phone_call model?
If anyone can help, Oh Wise Ones, please impart of thy wisdom!
murf
I am evaluating push notification services and cannot use services on the cloud as laws prohibit customer identification data being stored off-premise.
Question
Is there any chance data will be stored off-premise if I use AWS-SNS API (not the console) to send push notifications to end user devices via code hosted on-premise(using AWS SDK)? In other words, will SNS retain my data or will it forget it right after it send the notification?
What have I tried so far?
Combed through the documentation as much as I could, but couldn't find anything to be 100% sure.
Would appreciate any pointers on this. TIA.
I would pose this question directly to AWS as it pertains to a legal requirement. I would clarify if the laws you need to comply with are in relation to data at rest or in transit, or both. Additionally if there are any circumstances where it would be ok for one or both of the aforementioned if there was certain security aspects that have been met.
Knowing no real detail about your use case I will say that AWS has a Region specifically for use by the US Government. If your solution is for the US Government then you should be making use of this Region as it ticks off a lot of compliance forms for you well in advance.
You can open a support ticket in the AWS console.
Again if there is a legal requirement for your data I thoroughly recommend that you ask AWS directly so that you may reference their answer in writing in the future.
Even if they didn't store it, how can you prove that to auditors?
Besides, what is the difference between storing something in memory (which they obviously have to do) and storing something on disk? One is volatile and the other isn't I guess. But from a compliance point of view, an admin on the box can get both, so who cares if the hardware with your data on it is a stick of RAM or a disk plugged into a SATA port?
I'm using NetQueryDisplayInformation (I've already tried the NetUserEnum function) to get the set of user accounts on the local machine. I can get all the accounts this way - but I only want the accounts associated with actual human beings, and not, for example, hidden accounts used for software updates.
After reading the MSDN documentation on the relevant structures and similar Stack questions, I see nothing that can allow me to filter to just the accounts that I need.
Ideally, someone will have a simple and reliable solution that:
Doesn't involve using undocumented registry entries
Doesn't rely on enumerating user folders on disk
I'm not going to try to build an exhaustive list of non-real-user accounts
For technical reasons, WMI is not an option
Any ideas?
[Much later]
Got the answer, but not here - just enumerate the groups for each user. "Real human" accounts will be a member of one or more of Administrator, Power User, User, Guest.
You may be able to use the NetUserEnum function. It should return a list of all the user accounts on the system. I've not had to use this function personally so I can't provide any spectacular code examples, but the MSDN information sounds like what you are looking for.
You can use NetQueryDisplayInformation API, combine with bitwise check on user info flag.
I have exactly the same requirements, so I cook sample code (modified from MSDN GROUP query).
The user flags I used are:
UF_NORMAL_ACCOUNT
UF_ACCOUNTDISABLE
UF_PASSWD_NOTREQD ---> this ensure we get Human account, Human account always requires password.
working code at: http://www.cceye.com/list-system-normal-user-account-only/
I want to encrypt a given data using the log-in user's password on a windows machine using WINAPI. I've been looking for a function that uses a token (or something like that) but I couldn't find one.
Does anyone know how to do that?
Thanks! :-)
The Windows Data Protection API sounds like what you need. The CryptProtectData and CryptUnprotectData functions perform encryption using the logon credentials of the current user.
I had written this answer earlier but then reconsidered, since I hadn't heard of the DPAPI before. However, upon some further consideration, I'd like to offer the following opinion. The important preface here is that it all depends on your needs, though. Two conflicting possibilities come to mind:
You want to offer your user complete protection and encryption that the user can trust only she will be able to decrypt, no matter the circumstances.
You're an enterprise IT manager and have all employees on a tight leash. You want them to encrypt business data as part of their workflow so that they cannot see each other's data, but the admins can happily read everyone's data.
If you're in situation (2), then stop reading now and go with DPAPI, which is well suited to that case. If you prefer scenario (1), then read my original answer below.
That's probably not a good idea. Here's why:
The actual password will not be stored on the system (unless you have Windows 3.11 or something like that). Instead, only a hash of the password will be stored, and at login time the password that the user enters is hashed and compared to the stored hash.
So at best you could retrieve the stored hash from the system (if you have admin rights, say). However, if that's the only datum you can go on, then any encryption key you make will be derived from that hash, rather than from the actual password. Thus anyone with access to the system could get to the stored hash, and from there derive the encryption key with relative ease.
In short, don't. Ask the user for a dedicated, fresh password for your data and use it for only that.
use Kerberos (Linux-based authentication server, or other servers using Kerberos) / LDAP framework (Windows server) instead of designing your own login algorithm.
Windows Platform SDK & 3rd-party libraries have connectors with these frameworks.
More information in MSDN about Kerberos: http://msdn.microsoft.com/en-us/library/ff649429.aspx
How to safely store a password
Win32 bcrypt: http://msdn.microsoft.com/en-us/library/aa375421%28v=vs.85%29.aspx
I am trying to set up a (for now) really simple web service. By simple, I mean it only has a small amount of actual work to do on the code-side. It only really has one method/function: the client sends a user login, and the service responds with an otherwise very secure detail about the user (for the purposes of this question, let's say the user's birthday).
I have a lot of questions, but for now I'm wondering:
I am considering having two versions of this method. In version one, the client can only make a generic request with no variable information. The service will respond with birthday of whoever is authenticated in the client's session. In version two, the client is allowed to query any user name (so really, anything they want) and get back either the birthday or "Nothing found", etc.
The application of offering both would be so that most developers would get the birthdate of the current user so that it can be applied to that session. To extend my example: A user logs in, the developer wants to be able to have "Happy Birthday" if it is applicable. The owners of the service/data don't want the developer's client to have any access, real or conceptual, to anything about the user, even their log in, they just want to accommodate the developer's goal, as it is really nice. The developer doesn't want to be responsible for potentially having access to anything, he just wants to be nice.
Version two is available for some user-support groups. They actually need to look up birthdates of users who call in so that they can confirm that the user's are old enough to, let's say, rent a car. They may even have to look up multiple user's to see who is most eligible out of the group to get the best deal.
So I guess the big question, finally, is whether or not these two methods can exist in the same service?
The protocol, at this point, is more likely to be SOAP-based, then RESTful, so simply having URLs that both resolve to the same service but simply offer different methods is probably not an option.
What I need, ideally, is a way to reveal operations in the WSDL based on role. Obviously the documentation given to either group would reflect only the operation appropriate for the role, but ideally the developer/client would a) not see any operations they shouldn't and b) receive the same type of response for trying to use a forbidden response as they would a non-existent one and c) most ideally, receive the former-mentioned error because for their role the operation really DOESN'T exist, not because the service took extra precaution in case the client did try (which it will, FYI, but I don't want that to be the first and only level of obfuscation).
Am I dreaming the impossible dream?
Quick Addendum
I should have been more specific about this, I realize. When I say "role-based" I am referring to service-accounts, not user-accounts. So in my hypothetical situation above, the user-service app that would all for querying any user ID would be using one service-account with the privs to do so, not checking the role of the agent logged in to the session (which would be done to get to the app, obviously, but not to the service).
Why not have two methods:
GetMyBirthday();
GetBirthday(string userName);
Any user can call the first method; only privileged users can call the second method. You use role-based authorization and reject calls to the second method from unauthorized users.
I don't see why you'd want to hide methods in the WSDL based on roles. In many cases you'll be accessing the WSDL only to build a proxy in a development environment, and won't need it at runtime.