Goal
I have a backend service that talks to AWS, and an automated tool that acquires AWS creds. The cred-getter has MFA enabled (not my choice), but I don't want to type in or copy a code. Instead, I want to write a bit of code that can programmatically generate or get a TOTP soft-token without texting or calling anyone. So today our workflow is like this:
call cred getter from cli => open authy app for totp code => paste into cli
but i want it to look like this:
call my custom cli => it makes a totp code and passes it to cred getter for me
Question
Is there a way to curl Authy or Twilio to get one of these soft tokens programmatically?
Existing Docs
There's sort of a circular maze of documentation that appears relevant to this question, but I can't break the circle.
-----> Twilio has a page describing TOTP:
| | https://www.twilio.com/authy/features/totp
| |
| | It links to a page describing OTP API access:
| | https://www.twilio.com/authy/api#softtoken
| |
| | That explains you can "build your own SDK-supported mobile authentication application.":
| | https://www.twilio.com/docs/authy/api/one-time-passwords#other-authenticator-apps
^ v
| |
| | Which links to the quick start page:
| | https://www.twilio.com/docs/authy/twilioauth-sdk/quickstart
| |
<----- Which has a link about TOTP, which takes you back to the beginning
I see that the native mobile SDK's can generate a TOTP token:
https://www.twilio.com/docs/authy/twilioauth-sdk/quick-reference#time-based-one-time-passwords-totp
but I want to generate a token on a laptop (or cloud function or just someplace). The Authy Desktop client is doing it, so I know there must be a way. But I don't know what has been publicly exposed.
This question is relevant: how to get Google or Authy OTP by API
but the only answer depends on twilio calls and texts still: how to get Google or Authy OTP by API so that would be prohibitively expensive
Twilio developer evangelist here.
From what you've said, your credential getter provides you a QR code with which you then configure Authy to generate OTP codes.
The QR code encodes a URL in the following format:
otpauth://TYPE/LABEL?PARAMETERS
For example:
otpauth://totp/Example:alice#google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example
The type is likely "totp", like the example, the label will refer to the app you're authenticating with. The important part is the secret in the parameters. The secret is a base 32 encoded key that you can use to generate TOTP codes using the TOTP algorithm. There is likely an implementation of the algorithm in you preferred language.
Find the secret and you can generate your codes.
Related
I am trying to collect all active TIs via the Beta Graph API by following this. But it doesn't return anything. Here is what I use in Postman:
https://graph.microsoft.com/beta/security/tiIndicators
Response (200):
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#security/tiIndicators",
"value": []
}
A bit of context for the environment I work in.
The tenant has multiple Sentinel workspaces & resource groups.
The application I use has the correct permissions:
ThreatIndicators.Read.All
ThreatIndicators.ReadWrite.OwnedBy
ThreatSubmission.Read.All
ThreatSubmission.ReadWrite.All
It is my current belief that this might be due to the limitations of the Beta API. My reasoning is that accourding to this documentation you need the ThreatIndicators.ReadWrite.OwnedBy permission to access the API. This would suggest that currently you can only view TI's that the resource itself created.
If more info is needed just ask.
According to the documentation, ThreatIndicators.ReadWrite.OwnedBy permission allow you to manage threat indicators your app creates or owns.
If you want to read all the threat indicators for your organization then your app needs ThreatIndicators.Read.All permission.
Although this is not a solution to the question it is a workaround. By using the Log Analytics API you can get the TI via a KQL.
ThreatIntelligenceIndicator
| where ExpirationDateTime > now() and
NetworkIP matches regex #"^(?:(?:25[0-5]|(?:2[0-4]|1\d|[1-9]|)\d)\.?\b){4}$" and
ConfidenceScore > 25
| summarize by NetworkIP
This is probably better as you can also use a watchlist to exclude specific IP addresses with one request.
One thing I struggled with this was Authorization. You must give your Application permission to use the api.loganalytics.io API, and the application needs the Log Analytics Reader role in the Log Analytic workspace you want to use.
I am able to generate an oauth2 access token (from a refresh token), which I believe should give me the ability to access the youtube data api functionally to delete/upload content.
Using python and the youtube api I need to delete and upload a (new) video to youtube periodically, say hourly.
All google python samples I've found seem to call the "DENY/ALLOW" screen which requires a copy/paste back in the calling app.
I can do this occasionally but otherwise want the process to be automated. I've read about service accounts which, which according to the linked post, are not supported by the youtube api. Offline access et.al. is also mentioned but in somewhat abstract terms i.e. no concrete python examples (that I have yet found). Another source mentioned an http get like below:
"GET access_token=ya29.GlxBBS89....ast987&part=snippet&mine=true"
but the following in python doesn't seem to work returning "response [400]" (bad request)
url = 'https://www.googleapis.com/youtube/v3/channels'
args = 'access_token: ' + token var + ', part: snippet, mine: true'
get_token = requests.get(url, data = args)
I have used Can we use google youtube data api without OAuth (and others) to get to this stage but need clarification for the next step.
**********************************Update*********************************
I have found that I can only generate access tokens for clients credentials configured as web apps. I am writing a desktop app so I may be barking up the wrong tree.
Or learning Django...
I found examples at https://developers.google.com/youtube/v3/guides/auth/installed-apps that helped.
curl -H "Authorization: Bearer <access_token>" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true
curl https://www.googleapis.com/youtube/v3/channels?access_token=<access_token>&part=snippet&mine=true
The curl samples especially provided confirmation that I'm reaching the endpoint and returned helpful debugging info. They have exposed other issues which I'll ask in another question.
I need to secure a public facing HTTP API where I can not touch the code on the API server.
The HTTP API has multiple end-users that will consume it using non-interactive clients (typically backend services). Just to be clear, the client owns the resources that it will access and as such must provide a user since authorisation logic needs to be tied to a end-user.
I’m toying with the idea of using OAuth2 and the Resource Owner Password Credentials Grant
and then using the access token provided to get a JWT which the client can present to a HTTP proxy that parses the request before passing it to the HTTP API Server.
Here is the flow as I envision it:
+----------+ +---------------+
| |>--(A)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | (w/Refresh Token) |---------------|
| | | |
| |>—-(C)---- Request JWT ——-------->| JWT Service |
| | (w/Access Token) | |
| | | |
| |<--(D)---- JWT ------------------<| |
| | | |
+----------+ +---------------+
v
|
|
| +---------------+
| | |
| | HTTP |
--(E)---- HTTP Request w/JWT ---------->| Proxy |
| |
| (F) |
| |
+---------------+
v
|
(G)
|
v
+---------------+
| |
| HTTP |
| API |
| |
+---------------+
(A), (B), (C) Get an access token using the Password Grant flow.
(D) Use access token to get a JWT.
(E) Attach JWT to HTTP request and send it to the HTTP Proxy.
(F) Check that JWT is valid.
(G) Pass request to the HTTP API Server.
Has anyone else solved a similar use case and would care to shed some light or have a discussion?
OAuth2 has a number of advantages ...
It has a clear flow and multiple types of grants it can use to cater to different needs.
Another advantage is that there are libraries that deal with the complexities of OAuth2, such as Identity Server : https://identityserver.github.io/Documentation/
Whether it is overkill for your project or not, only you can answer that question. A lot of people who claim OAuth2 is complicated haven't really spent enough time trying to understand it.
What I advise you not to is to not rely on any kind of self baked security model as this is what causes the downfall of a system. OAuth2 libraries have been battle tested by lots of users and companies.
A lot of companies which provide apis do so via OAuth2.
So, bottom line, if you do want to use it, do your research ,understand it and then implement it.
As for your actual question, yes I have built similar systems with lots of users, using various grants and everything worked quite well. There's nothing to be scared about as long as you spend enough time knowing what you get yourself into ...
I'm getting downvoted for this answer, so I better explain myself.
I'm not the one to suggest "just write your own security libs", but I do make an exception with oauth+api clients (and especially oauth2).
Why not Oauth2?
extra hops & extra system components as compared to a traditional authentication scheme,
chances are that whatever you do, someone using some other programming language might not have a client library compatible with whatever you're using, people make money making oauth interoperable and simple
think about this: nobody makes money making ie basic authentication "simple, compatible with 1000s of providers and just working" (to quote oauth.io), that's because basic authentication just works on every "provider" and oauth2 is a bit of a shitty, complex, non-interoprable framework - that's why we call basic authentication a part of a "protocol", we call oauth(1) a protocol, but we call oauth2 a framework
think of the implications of maintaining a non-interactive client:
you have a single bearer token across the entire cluster,
so you will need a distributed key-value store or a DB table to hold it
You will need to capture specific errors that mean the bearer has
expired,
in which case you will want to seamlessly request the
bearer again and retry the request (without losing requests).
Problem here is that this on a busy site can start to happen in
parallel on 100s of threads
So, you need a distributed locking mechanism to do it right - redis mutex is my poison of choice when
someone greets me with an oauth api
That + good luck testing that piece of complex
distributed race condition logic, and when you break your back to do
it (hi webmock) and then you still get random non-deterministic failures from time to time because the gods of concurrency met some combination of conditions that VCR/webmock didn't handle nicely
this, or just SHA512 a secret together with a nonce and HTTP body
According to the lead author of the Oauth2 project: (my emphasis)
All the hard fought compromises on the mailing list, in meetings, in
special design committees, and in back channels resulted in a
specification that fails to deliver its two main goals — security and
interoperability. In fact, one of the compromises was to rename it
from a protocol to a framework, and another to add a disclaimer that
warns that the specification is unlike to produce interoperable
implementations.
When compared with OAuth 1.0, the 2.0 specification is more complex,
less interoperable, less useful, more incomplete, and most
importantly, less secure.
To be clear, OAuth 2.0 at the hand of a developer with deep
understanding of web security will likely result is a secure
implementation. However, at the hands of most developers — as has been
the experience from the past two years — 2.0 is likely to produce
insecure implementations.
...
In the real world, Facebook is still running on draft 12 from a year
and a half ago, with absolutely no reason to update their
implementation. After all, an updated 2.0 client written to work with
Facebook’s implementation is unlikely to be useful with any other
provider and vice-versa. OAuth 2.0 offers little to none code
re-usability.
What 2.0 offers is a blueprint for an authorization protocol. As
defined, it is largely useless and must be profiles into a working
solution — and that is the enterprise way. The WS-* way. 2.0 provides
a whole new frontier to sell consulting services and integration
solutions.
What to do instead?
Oauth is typically overkill unless you're creating a bigger eco-system.
Simpler solution is DIY, define a custom authorization header as:
authentication_id api_client_id nonce digest
ie
FooApp-SHA512-fixed 4iuz43i43uz chc42n8chn823 fshi4z73h438f4h34h348h3f4834h7384
where:
authentication_id is a a fixed string that describes what kind of authentication is being used,
api_client_id is a public piece of information identifying the API client (I assume the API has more than 1 client, or that it will have more than 1 client at some point) - API client ID is there to allow you to match the API client with the API clients' secret
nonce is just a random string
secret is a random string known only to you and the client and the client should treat it as a password (ie not commit it to versioning)
digest is a SHA512 hex/base64 digest of the api_client_id + nonce + secret (you can add also concatenate the HTTP body, I'd add the HTTP body unless the body is big - such as with file uploads)
If the client passes the authentication simply forward the request to the backend API service and return it's response to the client, otherwise render an error.
Parse.com's REST API docs (https://www.parse.com/docs/rest) say: Authentication is done via HTTP headers. The X-Parse-Application-Id header identifies which application you are accessing, and the X-Parse-REST-API-Key header authenticates the endpoint. In the examples with curl that follow, the headers are stored in shell variables APPLICATION_ID and REST_API_KEY, so to follow along in the terminal, export these variables.
I am building a Sencha Touch app as a native app on iOS and Android using Phonegap, and I was wondering whether it is secure to expose these keys to the client while making the REST calls?
Also, can someone explain to me how does security work in this scenario? Help is much appreciated! Thanks!
Without phonegap , in a proguard , post processed android apk , the string values of the 2 headers you mention are exposed client-side . not a big issue. TLS covers the http header values during network leg and far more important for app security, you have Full ACL at the DB row level(parse/mongo) contingent on permissions of 'current user()'. So with no access to logon, some outsider doesn't have any more than obfuscated string value to an app-level access token.
. One odd thing is that with parse the lease time on the client-side token value foapi key is permanent rather than say a month.
Parse REST security is robust n well executed.
Can't speak to what PG framework offers in obfuscate/minify/uglify area but you should check that.
I have a simple server-side command line python script, based on the now deprecated FT SQL API using Client Login for authorization.
Every few hours I refresh my FT by inserting the updated data. It's a small table, 3000 rows.
Read the FT Migration Guide, have a Google User id, enabled the FT API and have an API key, etc.
(Switching my Google Maps application to the new API was straight forward)
But I'm confused about how to proceed with migrating a command line python script. I see that OAuth2 is the recommended approach for authentication but it appears to me that this is a much more complicated approach than I truly need. It's not even clear to me that it will work for command line scripts.
Truly no need to prompt the user for login info (it's only me). I realize that this must be an "Installed app" and I found the Hello,python example at
https://developers.google.com/fusiontables/docs/sample_code#ftAPIv1
Haven't tried this yet but wanted to see if anyone has experience with migrating command line scripts. (PHP would work as well)
In particular I was intrigued by a quote I found here:
https://developers.google.com/fusiontables/docs/v1/using
"The Fusion Tables API also supports older authorization options, such as OAuth 1.0, AuthSub, or ClientLogin; however, in most cases we don't recommend using those other options. If your application already uses those options, we recommend migrating to OAuth 2.0 if possible."
Because, frankly I'd rather not switch to OAuth 2 for such a simple task.
UPDATE
Forgot to mention, I run this from cron, every 3 hours. So user input is not really possible. Though as David suggested below a one time user input is doable.
You should be able to use your Client Login token as your auth token for your existing server-side command line app with the new API. You'll also need to include your developer key in the request as the "key" parameter.
There is a very simple python implementation of the OAuth2 Installed Application flow here https://developers.google.com/fusiontables/docs/samples/python as you may have found, and yes, you should switch to this. ClientLogin deprecated just like the SQL API.
The Code requires you to open a browser and prompts you every time you use it and I'm going to speak to the author about optimizing it and having it store the Refresh Token and so it would only prompt the first time you use it.