UPDATE (201021) (I just copied my comment on the bottom here so that it's easy to read)

Just in case right now I tested few more with digits changing too, and found out that the ones I created with 1. 8digits + 60sec ☞ all conditions work (8digits+60sec, 6digits+30sec/60sec) 2. 6digits + 60sec ☞ only 6digits work (30sec/60sec) 3. 6digits + 30sec ☞ only 6digits 30sec work

• my app can only produce the tokens with 8d+60s, 6d+30s, and 6d60s that I could not test 8d+30s; but the pattern looks like changing to lower digits/timestep always works that the first token pretty sure will work with 8d30s as well.

I want to know if this only applies when I create tokens on my server or applies the same for the ones I create on /manage page, but I get empty User View on the page that I cannot check... (Even thought there are users on the db that I assign the token when I create it via /admin/init) I would really appreciate if somebody else can check it for me...

(201020)

Hi,

I've been changing the TokenInfo settings (digits and timesteps only) via the /manage page and found out that some tokens still work but some tokens don't...

[*all tokens have NO PINs]

• For example, I have a token A as sha256, 30sec, 6digits ☞ successfully authenticated
• I change it to sha256, 60sec, 6digits ☞ successfully authenticaed
• And now I have a token B with the settings of sha256, 30sec, 6 digits ☞successfully authenticaed
• I change it to sha256, 60sec, 6 digits ☞ WRONG OTP VALUE

I created token C and D to test more and found out that C works well in all conditions like A, but D doesn't work when it's 60sec.

30sec always works fine but 60sec... I have no idea what's going on

How can this happen? I'm so confused...

The secret is still the same (that it works when I change the setting back to 30sec), and I reset the fail counter before it hits 10.

I read that the self-service portal login issue (users aren't logged in, the page just refreshes), was fixed in 2.10.0.4 (I'm on 2.10.0.3). But there is no RPM newer than the version I'm on.

Is there a way to upgrade to fix this issue without breaking the RPM upgrade path in the future?

Hi ! I am currently testing LinOTP for an implementation of two-factor authentication within our small-size company (around 20 Employees). Is the two-factor authentication also supported when my Users log-in using the Selfservice portal? I have ad/ldap backend for my users and PW and tried to login using a test user-name and his password. Upon successfully authentication the password it was supposed to prompt the one-time-password token which I enrolled earlier, but didnt. Can I do two-factor when I use the selfservice?

With kind regards Jojo

It would appear that we are unable to set the Application Name. This is useful as it helps people with multiple tokens in an application distinguish one application from another.

I noticed validations of SMS OTP's failing on first attempt and then succeeding on second attempt. After some debugging, I found out that the first failure is because of a call to Challenges.verify_checksum(ch) in lib/tokenclass.py failing.

It seems when the challenge for the SMS is created, a MAC is calculated based on data with the timestamp when the Challange was initialised in model/init.py. For example, I saw this data being passed to verfiyMessageSignature: {"timestamp": "2017-02-24 22:55:28", "challenge": "sms submitted", "session": {"status": "open"}, "tokenserial": "LSSM00028763", "received_tan": false, "transid": "201618721774", "data": {"valid_until": "2017-02-24 23:00:29.166714"}, "id": 23, "valid_tan": false}

However, when writing the challenge to the database, a new timestamp is written, resulting in the following entry in the challenges table:

| 23 | 201618721774 | {"valid_until": "2017-02-24 23:00:29.166714"} | sms submitted | {"status": "open", "mac": "a64938b3b12bd16e6cefa435522824bf50dddc7fdd6b8e462d4539045cef6938"} | LSSM00028763 | 2017-02-24 22:55:29 | 0 | 0 | 0 |

A subsequent attempt to validate the SMS OTP fails, because it calculates a MAC with the data {"timestamp": "2017-02-24 22:55:29", "challenge": "sms submitted", "session": {"status": "open"}, "tokenserial": "LSSM00028763", "received_tan": false, "transid": "201618721774", "data": {"valid_until": "2017-02-24 23:00:29.166714"}, "id": 23, "valid_tan": false} - resulting in a different MAC.

This PR adds a new tokenissuer policy element (and related tests) that can be used to set the issuer portion of an OATH token in soft-tokens applications (similarly to the existing tokenlabel policy). Implementation follows the the otpauth:// URI format specification.

This has been tested on FreeOTP and GoogleAuthenticator as shown below:

Interesting thing is that when I used A PIN contains speical character # , it always returned

curl -k 'https://172.16.106.6/validate/check?user=31000013&pass=Abc#123884384'

{ "version": "LinOTP 2.10.1.1", "jsonrpc": "2.0802", "result": { "status": true, "value": false }, "id": 0 }

When I changed PIN to Abc!123, it was OK.

According to http://linotp.org/doc/2.6/part-management/policy/selfservice.html, I didn't set any policy about PIN.

Any idea ?

Guess # was specially treated before it was encoded and inserted to Database.

We have an issue with passing security scans due to below vulnerability:

124719 (1) - JQuery < 3.4.0 Object Prototype Pollution Vulnerability Synopsis The remote web server is affected by an object pollution vulnerability. Description The version of JQuery library hosted on the remote web server is prior to 3.4.0. It is, therefore, affected by an object pollution vulnerability in jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable proto property, it could extend the native Object.prototype.

URL : https://XXXXXXX/js/jquery-1.12.4.min.js Installed version : 1.12.4 Fixed version : 3.4.0

Any advise ?

The first time, when I finish all settings, Token and User ID is as following.

LinOtpTokenSerialnumber LinOtpUserid LSGO000378A8 badb6c22-904b-405b-860e-afab2c1d5499

But User ID is newly generated every time when LinOTP reconnects to LDAP after LDAP goes down due to some reason. Currenty, User ID is changed a new one. Which causes Token and User ID's association broken, and an exception " no user info".

It's pretty annoying, making OPT pointless. What I need to do is finding out old User ID from backup and inserting into table Token of Database by update Token set ... where ...

So anyway to fix this problem?

This PR adds an optional parameter to allow creation of simple pass tokens that can be used exactly once. Those can be useful as backup/recovery codes that can be self-provisioned in advance by users.

I noticed that you changed the path of packages from http://linotp.org/rpm to http://dist.linotp.org/rpm however some packages still point to the old path as a fail.

Even the documentation is pointing to the old path --> https://www.linotp.org/doc/latest/part-installation/server-installation/rpm_install.html

the following command yum localinstall http://linotp.org/rpm/el7/linotp/x86_64/Packages/LinOTP_repos-1.1-1.el7.x86_64.rpm

must be updated to: yum localinstall http://dist.linotp.org/rpm/el7/linotp/x86_64/Packages/LinOTP_repos-1.1-1.el7.x86_64.rpm -y

I tried to deploy LinOTP on Amazon Linux 2 (I have been using it for a long time on it), and when I installed the new package, it failed with error 404:

============================================ Full execution:

[root@ip-xxxxxxxxx bin]# yum localinstall http://dist.linotp.org/rpm/el7/linotp/x86_64/Packages/LinOTP_repos-1.1-1.el7.x86_64.rpm -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd LinOTP_repos-1.1-1.el7.x86_64.rpm | 5.8 kB 00:00:00 Examining /var/tmp/yum-root-RE0v5i/LinOTP_repos-1.1-1.el7.x86_64.rpm: LinOTP_repos-1.1-1.el7.x86_64 Marking /var/tmp/yum-root-RE0v5i/LinOTP_repos-1.1-1.el7.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package LinOTP_repos.x86_64 0:1.1-1.el7 will be installed --> Finished Dependency Resolution

Dependencies Resolved

Installing: LinOTP_repos x86_64 1.1-1.el7 /LinOTP_repos-1.1-1.el7.x86_64 2.1 k

Install 1 Package

Total size: 2.1 k Installed size: 2.1 k Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : LinOTP_repos-1.1-1.el7.x86_64 1/1 Verifying : LinOTP_repos-1.1-1.el7.x86_64 1/1

Installed: LinOTP_repos.x86_64 0:1.1-1.el7

Complete!

[root@ip-xxxxxxxxx bin]# yum update -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 amzn2extra-docker | 3.0 kB 00:00:00 amzn2extra-kernel-5.10 | 3.0 kB 00:00:00 http://linotp.org/rpm/el7/linotp/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found Trying other mirror.

One of the configured repositories failed (KeyIdentity LinOTP Packages for Enterprise Linux 7 - x86_64), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=linotp ...

 4. Disable the repository permanently, so yum won't use it by default. Yum
    will then just ignore the repository until you permanently enable it
    again or use --enablerepo for temporary usage:

        yum-config-manager --disable linotp
    or
        subscription-manager repos --disable=linotp

 5. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=linotp.skip_if_unavailable=true

failure: repodata/repomd.xml from linotp: [Errno 256] No more mirrors to try. http://linotp.org/rpm/el7/linotp/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

[root@ip-xxxxxxxxx bin# yum install LinOTP -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 amzn2extra-docker | 3.0 kB 00:00:00 amzn2extra-kernel-5.10 | 3.0 kB 00:00:00 http://linotp.org/rpm/el7/linotp/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found Trying other mirror.

One of the configured repositories failed (KeyIdentity LinOTP Packages for Enterprise Linux 7 - x86_64), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=linotp ...

 4. Disable the repository permanently, so yum won't use it by default. Yum
    will then just ignore the repository until you permanently enable it
    again or use --enablerepo for temporary usage:

        yum-config-manager --disable linotp
    or
        subscription-manager repos --disable=linotp

 5. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=linotp.skip_if_unavailable=true

failure: repodata/repomd.xml from linotp: [Errno 256] No more mirrors to try. http://linotp.org/rpm/el7/linotp/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

============================================

Please update the package with the new base URL or put a mirror on the old URL until the error is fixed.

Thanks! Guillermo

Already has been asked in #184 , but the issue is closed without actual resolution.

Can you keep this open so anyone (including myself) can hook their subscriptions and be notified once packages are released and issue resolved?

Thx

Good afternoon!

For various reasons, we (and I'm sure we're not alone in this) would need "officially" maintained RPM sources of LinOTP upstream in order to properly use it. Even though I can successfully build it, our compliance profile really needs us to use an official standard source that requires it to come from the upstream.

I'm therefore considering submitting a PR/merge with an RPM SPEC file for the repository as is, to build its current state on an on-going basis. This should enable relatively easy CI/CD. However, I'd like to understand if there's an opposition to the 3.x series on EL7/8 prior to investing this time? Or if the matter is more practical in nature?

Please let me know, and I'll work on the SPEC file. Creating these RPM artifacts would be incredibly ideal, as we (and I'm sure others) could then use 3.x readily.

THANKS! Michael S. Moody

(Open for any comments)

Hello All,

I'm facing an error "Lock wait timeout exceeded; try restarting transaction". With this error, some users cannot authen to the system. After I restart the web service, those users can authen to the system.

• LinOTP logs: "2022/11/14 - 15:50:01 ERROR [linotp.controllers.validate][simplecheck #829] [simplecheck] failed: OperationalError("(OperationalError) (1205, 'Lock wait timeout exceeded; try restarting transaction')",) "

• Radius log: "Mon Nov 14 15:49:16 2022 : WARNING: (26) WARNING: Module rlm_perl became unblocked Mon Nov 14 15:49:22 2022 : Error: (27) Ignoring duplicate packet from client IDC_EXT_FW port 45378 - ID: 50 due to unfinished request in component authenticate module perl Mon Nov 14 15:49:32 2022 : Error: (27) Ignoring duplicate packet from client IDC_EXT_FW port 45378 - ID: 50 due to unfinished request in component authenticate module perl Mon Nov 14 15:49:48 2022 : Error: Unresponsive child for request 27, in component authenticate module perl Mon Nov 14 15:50:01 2022 : Info: rlm_perl: return RLM_MODULE_REJECT "

This issue appears frequently. Does anyone have a solution for this issue?

Thank You and Best Regards, Dat

Hello,

I have LinOTP 2.12.5 deployed in AWS.

I have a pair of Amazon Linux EC2 instances with LinOTP with a load balancer in front.

The resolver is created by a bootstrapping script, that installs LinOTP and the components.

We use LDAP resolvers, however, I was not able to configure the Bind Password by the script so I need to enter it manually.

I configured the 1st server without any issues. I edit the resolver, paste the Bind Password, click on the LDAP Test button, and works perfectly. Click on the Save button and everything is OK.

When I configured the 2nd server. I edit the resolver, paste the Bind Password, click on the LDAP Test button, and works perfectly. Click on the Save button and then got this "Error saving ldap configuration.: (OperationalError) (1045, "Access denied for user 'linotp'@'xx.xx.xx.xx' (using password: YES)") None None" I'm not able to continue. And the second server is not able to authenticate any users.

Any suggestion to deal with this issue? Thanks!