I am able to sign single container multiple times that's good but I am also after counter sign.
Is counter sign achievable using cosign?
https://github.com/sigstore/cosign/blob/main/USAGE.md
Related
We've been using password-less login feature from flask-security for some time but we now discovered that login link can actually be used multiple times which is not ideal security-wise. I've spent some time reading through https://flask-security-too.readthedocs.io/en/stable/configuration.html trying to find a setting which would make login token invalid after first use but I only came across SECURITY_LOGIN_WITHIN option that sets the token's lifetime. What I would like would be:
token made invalid once used
token expired if not used within ..
Does flask-security provide such a config?
You are correct - these tokens aren't one-time - but they are timed - so the token will expire if not used after SECURITY_LOGIN_WITHIN seconds (which is your second ask).
The newish feature - unified_signin provides a more flexible way of providing authentication - including email links (like passwordless) or one-time codes, SMS, authenticator app.
In unified_signin - all the codes are generated using passlibs TOTP - which are ALSO timed tokens - not truly one time. However - as documented here: https://flask-security-too.readthedocs.io/en/stable/api.html#flask_security.Totp
you can implement the recommended counter persistence to ensure one-time use/no replays.
app.config['SECURITY_LOGIN_WITHIN'] = "10 minutes"
is a good value.
If the link has expired, a new message is sent (flask-security-too)
I'm writing a webservice in Go.
Upon login, the user is returned a token, which behaves roughly like a cookie in the sense that the user must pass it in each subsequent request in order to be recognized.
Does my token generator has to be "cryptographically secure", ie. generated with high entropy?
How can I achieve this in Go, preferably using standard libraries or libraries written by crypto-competent people unlike me?
It would be beneficial for the token generator to be cryptographically secure, to reduce the ability of attackers to guess new session tokens and acquire the privileges along with them. crypto/rand implements such a random number generator, including functions that allow you to generate random integers, prime numbers and bytes suitable for this.
Yes, use a crytographic hash. You can use something like gorilla/securecookie to generate a key and provide cookie storage: http://www.gorillatoolkit.org/pkg/securecookie
Note that if you are relying upon the cookie alone for verification that you open yourself up to replay attacks. Use the cookie to trigger a server-side check (user ID == active/valid) or bounce then out if the ID doesn't exist.
I am following the instructions here:
http://getpocket.com/developer/docs/authentication
To authenticate access to the pocket API.
My question is how much of this do I have to do the second time a user uses my app?
I presume that I retain one of the tokens or codes and use that the second time. I certainly don't see the authentication page every time I used Tweetdeck for example.
What best practice is there for giving a user an option to not automatically sign them in next time if its a public computer for example?
Thanks
You should keep the access token that you get during the "first" process, meaning the first time the user authenticated. Then you can use it for the next times.
I've been curious as to how google generates one time log in tokens on an iPhone app without comminicatig with the server when the token is Assigned. The token changes every ten seconds. How does google know what the right token is? I disabled data and it still works.
Thanks
it uses your unique key during setup as well as a special sequence/algorithm (that's part of the authenticator program (in your case, the iPhone .app)) to generate a special key. As part of the key-generating process, it also uses the current time on your iPhone to match up with the computer time you are logging in from.
remember a verification code, wait for the current code to expire, and continue logging into your google account on your computer with your previously memorized code. it will still work. try changing the time on your phone by 20 minutes off or something, and use a newly-generated code, it will not work.
it works similar to the HSBC security dongle keychain thinggy (for online banking) if you have one.
Google Authenticator generates OTPs based on the secret key. The secret key (seed) is 16 or 32 character alphanumeric code. In the process of token enrollment, the server generates the secret key and shares it with your phone via QR code (or you can enter it manually). For example, when TOTP algorithm is used, server and Google Authenticator know the seed and the current time and based on this information they generate the same one-time passwords (OTPs) at predetermined intervals. So the key elements are the secret key and time. Google Authenticator doesn’t require any internet connection or mobile network.
I have a security number generator device, small enough to go on a key-ring, which has a six digit LCD display and a button. After I have entered my account name and password on an online form, I press the button on the security device and enter the security code number which is displayed.
I get a different number every time I press the button and the number generator has a serial number on the back which I had to input during the account set-up procedure.
I would like to incorporate similar functionality in my website. As far as I understand, these are the main components:
Generate a unique N digit aplha-numeric sequence during registration and assign to user (permanently)
Allow user to generate an N (or M?) digit aplha-numeric sequence remotely
For now, I dont care about the hardware side, I am only interested in knowing how I may choose a suitable algorithm that will allow the user to generate an N (or M?) long aplha-numeric sequence - presumably, using his unique ID as a seed
Identify the user from the number generated in step 2 (which decryption method is the most robust to do this?)
I have the following questions:
Have I identified all the steps required in such an authentication system?, if not please point out what I have missed and why it is important
What are the most robust encryption/decryption algorithms I can use for steps 1 through 3 (preferably using 64bits)?
Your server has a table of client IDs and keys. Each client also knows its own key.
The server also maintains a counter for each client, initialised to zero. Each client maintains a counter, also initialised to zero.
When the button is pressed on the client, it generates a HMAC of the current counter value, using its key as the HMAC key. It generates an alphanumeric code from the HMAC output and displays that to the user (to send to the server). The client increments its counter value.
When an authentication request is recieved by the server, it repeats the same operations as the client, using the stored key and counter for that client. It compares the alphanumeric code it generated with the one recieved from the client - if they match, the client is authenticated. If they do not match, the server increments its counter for that client and repeats the process, for a small number of repetitions (say, ~10). This allows the server to "catch up" if the client counter has been incremented without contacting the server.
If the counter rolls over to zero, the server should not accept any more authentication requests for that client ID, until it is issued a new key.
There are extensions to this basic protocol: For example, instead of a counter, you can use synchronised clocks on the server and client (with the value changing every N seconds instead of every button press).
What you're describing is called an HOTP, or HMAC-based One Time Password. Implementation is described in this RFC, and unless you have a compelling reason not to, I'd strongly suggest implementing it as-is, since it's been vetted by cryptographers, and is believed secure. Using this will also give you compatibility with existing systems - you should be able to find HOTP-compatible tokens and software apps, like Google Authenticator for Android.