I am trying to replicate the functionality of Authy/Google Authenticator for a private application. What algorithm should I use to get the 6 or 8 digit 2fa-code from a known secret? Is there an open-source package for this?
These are generated using the Time-Based One-Time Password (TOTP) Algorithm. RFC at https://datatracker.ietf.org/doc/html/rfc6238. There are many packages available for this depending on your preferred programming language. (You can search for TOTP <your language> on google to find packages that do this)
Once you have the key, the OTP can be generated based on the current time.
Related
I am writing an application that should interact with DocuSign to create envelopes and then download the signed document when all the signatories have signed.
There are several other use cases, but that does not matter for this question.
I am wondering what is the best way to write automated integration tests.
Do I need to automate the interaction of the signatories withe DocuSign? This would mean that I have to receive the email, click the link, etc...
Even if it seems possible, it does not seem ideal. Is there a way to "simulate" in a dev environment the actions of the signatories?
There has been a lot of talks if a document can be signed without viewing it. And the conclusion was that NO, user cannot sign a document without viewing it. User has to view/see what is to be signed. So, that part needs to be automated using Selenium or one of its "flavors" or pretty much any UI automation you are comfortable with. And Yes, that involves receiving email, clicking the link, opening a document and signing it. You can use a Mailinator or any other email service which API you can leverage to facilitate things for you.
As for other parts of DocuSign integration automation it is encouraged to use API (makes things more stable).
So, very simple workflow steps would look like this:
Use API to prepare environment, sent variables and values (in your product and in DocuSign)
Send envelope for signing using DocuSign API
Get the link to the document
Sign using UI automation
Do verification (of envelope status and more) using DocuSign API
I am implementing Time based OTP (TOTP) for my network security course. The last time I gave presentation my instructor asked me "If you're going to share secret key by generating QR code and then letting the client(soft token) scan it, how are you sure that its safe ? " He meant that how the procedure of getting key from database and then making its QR code is safe ? If a third party have access to that web page then ? can third party know secret key without scanning code ?
I'm so confused from his questions.
Most probably the question was with generating the QR code, not really about the security of the shared secret itself (there is nothing you can do more about transferring the shared secret - you have to somehow share it).
What you have to be careful about when it comes to QR generation - do not use external services (like google chart) to generate the QR code, you have to do it with minimum external library use - ideally purely on the client side.
Here is an example https://github.com/token2/totp-toolset-local
I am trying to create a skill that will reach out to an application that uses Basic authentication to render APIs (albeit i know this is bad practice). I was wanting to go down a route similar to account linking, however seems they enforce the usage of OAuth 2.0.
Is there an alternative to this or am I forced to use OAuth 2.0 in order to request APIs to a 3rd party application?
My wanted workflow:
customer enables skill
Skill card request for username/pw combo
after setup, the skill can be utilized fully
Not sure if its helpful, but Im using Lambda to run my skill source code.
That is a terrible practice.
First of all, what if your user's password includes case sensitive letters and numbers and possibly other characters?
You can use Literal Slots but they are not case sensitive and probably won't return a number-word combination either. For example your user's pass is Word123 literal slots may return word one two three
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interaction-model-reference#literal-slot-type-reference
I am not sure if you can force user to spell his password's characters and so then you can try to detect the password though... Again this sounds like a terrible practice.
So as you mentioned: Users link their accounts using the Amazon Alexa app. Note that users must use the app. There is no support for establishing the link solely by voice
I guess you have to do the linking the way amazon requires
https://developer.amazon.com/blogs/post/Tx3CX1ETRZZ2NPC/alexa-account-linking-5-steps-to-seamlessly-link-your-alexa-skill-with-login-with-amazon
I have written an R package that connects to some services
requiring username and password.
I want to avoid typing my username and password
every time, so I have my package read them from a file
encrypted using AES (I use the digest package in a way similar to the answer to this question: How do I read an encrypted file from disk with R)
The AES key is generated when a user installs the package and it is used to encrypt and decrypt the users credentials.
This way the users only need to insert their credentials once at the moment
of installation and then do not need to write them in any place in the code.
However if somebody gets access to their laptop, it is very easy for him to
decrypt the credentials using the key generated by my package.
Is there any way I can protect the key (possibly in a cross-platform manner,
since the package has to be used in Windows, Linux and Mac)?
The best way to protect encryption keys are Hardware Security Modules like Thales PayShield / nCipher or SafeNet PSO / PSW / Luna, etc... The Key Encryption Keys (KEK) are stored on separate devices and in OS you just keeping cryptograms, keys encrypted under secret key to which you can not get any access (such devices are strongly secured from "intrusion"), The code to use such devices you can write on Java or Python for example, it will make your software OS independent. But it costs some money :)
Background: This is my first standalone web development project, and my only experience in Meteor is building the Discover Meteor app over the last summer. I come from about a year of CS experience as a side interest in school, and I am most comfortable with C and C++. I have experience in python and java.
Project so far: I'm creating a calendar management system (for fun). Using accounts-google, I have created user accounts that are authenticated through google. I have requested the necessary permissions that I need for my app, including 'identity' and 'calendar read/write access'. I've spent the last week or so trying to get over this next hurdle, which is actually getting data from google.
Goal: I'd like to be able to make an API call to Calendar.list using a GET request. I've already called meteor add http to add the GET request functionality, my issue comes with the actual implementation.
Problem: I have registered my app on the developer console and set up Accounts using the client ID and secret, but I have not been able to find/generate my 'API key' for use in the request. Here is the google guide for creating the access token by using my (already) downloaded private key. I'm having a hard time wrapping my head around an implementation on the server side using JS because I don't have a lot of experience with what is mentioned in the HTTP/REST portion of the implementation examples. I would appreciate some help on how to implement a handshake and receive an access token for use in my app. If there is a call I can make or some package that will handle the token generation for me, that would be even better than implementation help. I believe an answer to this would also benefit this other question
The SO answer that I've been referring to so far: https://stackoverflow.com/a/14543159/4259653 Some of it is in spanish but it's pretty understandable code. He has an API key for his request, which I asked this question to help me with. The accounts-google documentation isn't really enough to explain this all to me.
Also an unrelated small question: What is the easiest way to deal with 'time' parameters in requests. I'm assuming JS has some sort of built-in functionality that I'm just not aware of yet.
Thanks for your research. I have also asked a very similar question, and right now I am looking into the package you recommend. I have considered this meteor-google-api package, but it looks abandoned.
Regarding your question about time manipulation, I recommend MomentJS. There are many packages out there; I am using meteor add mrt:moment
EDIT: MomentJS now has an official package for Meteor, so use meteor add momentjs:moment instead of the mrt command above
Below is a snippet of what moment can do. More documentation here.
var startTimeUTC = moment.utc(event.startTime, "YYYY-MM-DD HH:mm:ss").format();
//Changes above formatting to "2014-09-08T08:02:17-05:00" (ISO 8601)
//which is acceptable time format for Google API
So I started trying to implement all of this myself on the server side, but was wary of a lot of the hard-coding I was doing and assumptions I was making to fill gaps. My security prof. used to say "never implement encryption yourself", so I decided to take another gander for a helpful package. Revising search criteria to "JWT", I found jagi's meteor-google-oauth-jwt on Atmosphere. The readme is comprehensive and provides everything I need. Following the process used in The Google OAuth Guide, an authorization request can be made and a key generated for making an API call.
Link to Atmosphere: https://atmospherejs.com/jagi/google-oauth-jwt
Link to Repo: https://github.com/jagi/meteor-google-oauth-jwt/
I will update this answer with any additional roadblocks I hit in the Google API process and how I solved them:
Recently, I've been running into problems with the API request result. I get an empty calendarlist back from the API call. I suspect this is becuase I make an API call to my developer account rather than to the subject user. I will investigate the problem and either create a new question or update this solution with the fix I find.
Fix: Wasn't including the 'sub' qualifier to the JWT token. Fixed by modifying JWT package token generation code to include delegationEmail: user.services.google.email after scope. I don't know why he used such a long designation for the option instead of sub: as it is in the google API, but I appreciate his package nontheless.
I'm quickly becoming proficient in this, so if people have meteor-related google auth questions, let me know.
DO NOT USE SERVICE ACCOUNTS AS POSTED ABOVE!
The correct approach is to use standard web access + requesting offline access. The documentation on the api page specifically states this:
Typically, an application uses a service account when the application uses Google APIs to work with its own data rather than a user's data.
The only exception to this is when you are using google apps domain accounts and want to delegate access to your service account for the entire domain:
Authorizing a service account to access data on behalf of users in a domain is sometimes referred to as "delegating domain-wide authority"
This makes logical sense as a user must be allowed to "authorise" your application.
Back to the posters original question the flow is simple:
1) Meteor accounts google package already does most of the work for you to get tokens. You can include the scope for offline access required.
2) if you are building your own flow, you will go through the stock standard process and calls as explained on auth
This will require you to:
1) HTTP call to make the original request or you can piggyback off some of the internal meteor calls : Package.oauth.OAuth.showPopup() -- go look at the source there are more nifty functions around there.
2) Then you need to create an Iron router server side route to accept the oauth response which will contain a code parameter that you will use to exchange for tokens.
3) Next use this code to make a final call to exchange the "code" for the token + refresh_token
4) Store these where ever you want - my requirement was to store them not at the user level but multiple per user
5) Use a package like GoogleAPI this wraps up Google API calls and refreshes when required - it only works when tokens are stored in user accounts so you will need to rip it apart a bit if your tokens are stored somewhere else (like in my case)