Clipperz.PM.DataModel.User.exception.LoginFailed

[DaPutzy]

on a fresh install I:

• edited "configuration.php"
• followed "setup/index.php"
• went to "gamma/index.html"
• tried to create a new user:

Frontend-Error:

Clipperz.PM.DataModel.User.exception.LoginFailed

PHP-Error:

2015/05/27 22:01:46 [error] 27473#0: *305 FastCGI sent in stderr: "PHP message: registration
PHP message: result: {"result":{"lock":"","result":"done"}}" while reading response header from upstream, client: 77.64.189.242, server: U_DONT_NEED_TO_KNOW_MY_DOMAIN, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "U_DONT_NEED_TO_KNOW_MY_DOMAIN", referrer: "http://U_DONT_NEED_TO_KNOW_MY_DOMAIN/gamma/index.html"
2015/05/27 22:01:47 [error] 27473#0: *305 FastCGI sent in stderr: "PHP message: handshake
PHP message: result: {"result":{"s":"1fd35b3b4acbb0e4bebfbd18e0dcd4f32a5e956b0946c9b1ec0001a9dda74103","B":"1caac82469682f108ed5ce1df76bc73e2956b0ab1d8462b48b31d6d20c02c0b06"}}" while reading response header from upstream, client: 77.64.189.242, server: U_DONT_NEED_TO_KNOW_MY_DOMAIN, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "U_DONT_NEED_TO_KNOW_MY_DOMAIN", referrer: "http://U_DONT_NEED_TO_KNOW_MY_DOMAIN/gamma/index.html"
2015/05/27 22:01:47 [error] 27473#0: *305 FastCGI sent in stderr: "PHP message: handshake
PHP message: credentialCheck
PHP message: result: {"result":{"error":"?"}}" while reading response header from upstream, client: 77.64.189.242, server: U_DONT_NEED_TO_KNOW_MY_DOMAIN, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "U_DONT_NEED_TO_KNOW_MY_DOMAIN", referrer: "http://U_DONT_NEED_TO_KNOW_MY_DOMAIN/gamma/index.html"
2015/05/27 22:01:47 [error] 27473#0: *305 FastCGI sent in stderr: "PHP message: handshake
PHP message: result: {"result":{"s":"112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00","B":"d2661284a6ec0759727a35c497250b46978f61acbace3b43ee8c4b566d96b476"}}" while reading response header from upstream, client: 77.64.189.242, server: U_DONT_NEED_TO_KNOW_MY_DOMAIN, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "U_DONT_NEED_TO_KNOW_MY_DOMAIN", referrer: "http://U_DONT_NEED_TO_KNOW_MY_DOMAIN/gamma/index.html"
2015/05/27 22:01:48 [error] 27473#0: *305 FastCGI sent in stderr: "PHP message: handshake
PHP message: credentialCheck
PHP message: result: {"result":{"error":"?"}}" while reading response header from upstream, client: 77.64.189.242, server: U_DONT_NEED_TO_KNOW_MY_DOMAIN, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "U_DONT_NEED_TO_KNOW_MY_DOMAIN", referrer: "http://U_DONT_NEED_TO_KNOW_MY_DOMAIN/gamma/index.html"

[w112nxs]

facing the same issue

[dariowho]

Hi guys, just a reminder: here at Clipperz we are alive and kicking, but we cannot provide support for user contributed backends. However, we would be glad to have a maintainer for the PHP version onboard: if anyone is up for this let's get in touch!

Best, Dario

[isabelacristinaterra]

the same issue

[Yumash]

same one trying to find the reason.

[jokajak]

This is due to the login code being updated on the client side without a corresponding update on the server side.

[brainthee]

Confirmed, I'm seeing this too. I've tried beta and delta frontends with the php backend.

Clipperz is by far one of the best online password managers out there. The ability to self host is awesome. But you are leaving us out to dry by not updating the backend while you update the frontend is pretty much saying you don't care.

[jokajak]

As they have already mentioned, they do not have resources to support the php backend but are happy to accept patches.

[brainthee]

You say that but there is an open pull request to fix a remote eval vulnerability still outstanding. The fixed code is available there but they havnt merged. Been there for around a year now. I understand they don't want to support these back ends but why keep insecure/buggy code as part of the core project if there is no intention to accept community help, let alone support it.

This is what I mean, conflicting messages!

[mbarulli]

Hi everyone,

we are clearly stating since a long time that the open source version of Clipperz is just to be used for security reviews and educational purposes. The provided backends are very basic and their only goal is to support communication with the frontend.

Therefore it is not recommended to use any self-hosted version of Clipperz for storing sensitive data. We released them just to allow anybody to learn and play with a zero-knowledge web app.

We are now actively working for making Clipperz much more than a password manager and an online encrypted vault. It works great to store passwords and important files, but we have even bigger plans. Take a look at the website to learn more.

Thanks for your support and feel free to contact me for any further clarification.

Cheers, Marco

[aunxx]

Hi.

I'm not sure if anyone still is interested in using the PHP based backend, but I've just spent the last few days trying to work out what was happening to stop the login process from working. I've had to debug a lot of the javascript front end and php backend trying to work out where the crypto was failing. There seems so of been a couple of problems on both sides negotiating the values, but I've eventually found a working solution and can login again on fairly recent code (Testing on the beta frontend, but all the code should be interchangeable with the other backends.) I will try and put the code back into original branch I've checked out and try and make it available if anyone is interested, but I'm fairly sure that it will not be compatible with the current python backend. ( I couldn't get the python backend to work from a default checkout, so that may well be broken as well. )

I wouldn't say I've tested the updated code thoroughly, but it seems to be functional. I'll update here if I manage to roll the changes back into my local branch of the repository.

Graham.

[aunxx]

Hi.

I've moved the changes back into my branch of git, and it works for beta and gamma, but it looks like the handshake between the client and the server in Delta has changed, and it'll need more work to fix. Other than that, it seems to be working in the compiled version. (Or, I've not managed to break it completely yet. I haven't tried one time passwords yet either) Off line copy also seems to be broken, but that shouldn't be too tricky to fix. (Hopefully)

Time is, as always, something I do not have much of. :(

Graham.

[mbarulli]

Hi Graham, thanks for working on this! :)

Cheers, Marco

[aunxx]

Hi.

No worries. It's been quite an interesting learning curve as it's been a long time since I've worked with php or javascript. :)

I've got a bit further with the code. I've found and made a couple of changes to the delta frontend so it now seems to be working. Again, I've not tested it extensively as I've only just finished.

The biggest problem i have left to look at is to do with the BigInt Javascript library. Specifically that it only supports unsigned integers. Part of the encryption handshake is: S = (B - kg^x) ^ (a + ux) (computes session key) Now, if kg^x > B the first part is negative. This breaks everything as the result is a twos compliment number. It can be bypassed slightly by reversing the order to (kg^x -B) and ensuring that (a + ux) is even. When (a + ux) is odd, the signed-ness of the equation breaks again. This I can fix, but will involve logic in the equation. Essentially, some passwords just don't work at the moment. :(

I'll update my git branch and test. Hopefully I'll fix that authentication problem and be able to release the changes back into a branch of the code here.

Cheers, Graham.

[aunxx]

Hi.

I've finally configured my webserver to allow access to my repository. Try cloning from:

http://git.whoc.org.uk/git/password-manager.git

Most of the changes are in a couple of files, and I'm fairly sure it isn't compatible with the main branch any more, but it works with PHP as a backend. There are problems if you try to update an old install with this code, but new installs seem to be okay. Any old installs can be persuaded to work with some mysql changes though.

Cheers, Graham.

[pjamar]

I'm interested in your branch, aunxx, but the URL you provided led me to an empty page. Would it be possible to have your branch in Github as well?

Thanks!

[aunxx]

Hi. I've disabled the HTTP element of the git server, but you should be able to clone using something like: git clone http://... from a terminal.

If you've still problems accessing the repo, then let me know and I'll see what I can do.

Cheers, Graham.

[jkotev]

Hi, Graham repo is not available...can you fix?

[aunxx]

Hi.

Sorry, modsecurity update broke it. I've tested it and it should be working now. I'll try and include the update to the mysql code so it'll work with php7.0 this evening.

Cheers, Graham.

[jkotev]

thanks!

but when i try to install now:

root@clipperz.chiitdc1.outbrain.com:~/password-manager# ./scripts/build install --backends php --frontends beta Traceback (most recent call last): File "/root/password-manager/scripts/builder/main.py", line 197, in main() File "/root/password-manager/scripts/builder/main.py", line 191, in main build(settings, currentRepository) File "/root/password-manager/scripts/builder/main.py", line 93, in build raise Exception("repository has pending changes, can't 'install'") Exception: repository has pending changes, can't 'install'

[aunxx]

Hi.

I've just tested, and it works for me, but I've had this problem before. It's linked to the state of the git repository. Lines 92 and 93 of scripts/builder/main.py are:

#                       print "\nWARNING: repository has pending changes\n"
                         raise Exception("repository has pending changes, can't 'install'")

---

Simply uncomment the first line and comment the second so it looks like:

                         print "\nWARNING: repository has pending changes\n"
 #                       raise Exception("repository has pending changes, can't 'install'")

Cheers, Graham.

[jkotev]

works now! 10x a million.

[Git-Rajkumar]

@aunxx i have cloned your repo, your code also throw same error.

what i did: I have cloned yuour repo

  $git clone http://git.whoc.org.uk/git/password-manager.git
  $ cd password-manager
  $ ./scripts/build clean install debug --frontends beta --backends php 
  $ cp target/php/*  /var/www/html/

Then go to http:host/setup

 then click **POG up  and Proceed**.

 Then remove  setup folder

Finally go to home page http://host/beta/

Then register new user, its saved to database but its not login its throw same error, Suggest me Any other way to fix this. reference: https://github.com/clipperz/password-manager/issues/121

[aunxx]

Hi.

Which version of PHP are you using?

Specifically, what is the error? is it the same as the name of this thread?

Cheers, Graham.

[aunxx]

Found some issues with the code in my repository when using PHP7. Please pull the latest version and try again. (tag v1.0.2) This version has been updated for the mqsqli functions rather than the deprecated mysql functions. (POG also updated and tested)

Cheers, Graham.

[meoso]

@aunxx Thank you for your repo, would you submit pull request to clipperz team? Yours works, theirs does not. For all trying to get this working, I failed on RHEL7, but succeeded Ubuntu 16.04 due to newer package versions.

[aunxx]

Hi All, I'm not sure if anyone is still using this, but I found a problem in the offline backups which prevented logins. I've updated the code in my repository to v1.0.3 which fixes this now for the three front ends. This now diverges from the original code with the following changes: 1) Working PHP backend 2) Working offline copies 3) now uses the mysqli functions 4) I've updated the SRP functions to generate the hashes from base 10 numbers rather than hex. This shouldn't impact any security, but makes it currently incompatible with the python back end.

I've most of the code to update the current encryption to 2048 bit, but that would be incompatible with the existing versions.

[aunxx]

Hi All,

It seems that the new default setup for mariadb is enforcing strict datetime format, and so new records are failing to be added. I'll fix the php code and update the repo in a few days.

Not sure if anyone else is still using this, but beware adding records as they may not save correctly, and the information will be lost.

[aunxx]

Hi All,

I've updated my repo to include the v1.0.5 tag which now works for me. if your database is using strict mode (see https://mariadb.com/kb/en/library/sql-mode/ ) then you need this version.

Any issues, then post them here.

[emroom]

Hi Graham,

Your efforts are much appreciated!!! I am planning on switching (back!) to Clipperz on Ubuntu 18.04 and your updates make all the difference. Thanks a lot, sir.

Edwin.

[emroom]

Hi,

I have reinstalled Clipperz and ran the "POG me up" thingy. But when I redirect to /clipperz2, I get:

{"result":{"result":null}}

When I check apache2 log, I see:

AH01071: Got error 'PHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 179\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 180\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 189\nPHP message: PHP Notice: Only variables should be passed by reference in /var/www/html/clipperz2/setup/rpc.php on line 196\n', referer: https:///clipperz2/setup/index.php

and

AH01071: Got error 'PHP message: PHP Notice: Undefined index: method in /var/www/html/clipperz2/php/index.php on line 224\n

Do you have any clue? I tried Googling these errors but did not find a suitable answer...

Edit: found something so changed line 224 and further to:

    $method = isset($_POST['method']) && trim($_POST['method'])!='' ? $_POST['method'] : '';

    if (get_magic_quotes_gpc()) {
            $parameters = isset($_POST['parameters']) && trim($_POST['parameters'])!='' ? json_decode(stripslashes($_POST['parameters']), true) : '';
    } else {
            $parameters = isset($_POST['parameters']) && trim($_POST['parameters'])!='' ? json_decode($_POST['parameters'], true) : '';
    }

[aunxx]

Hi. Thank you for your comments the other day. :)

That error comes from the base directory, as the index.php there is mainly routines used by the front-ends. Depending on which of the 3 frontends you compiled (Normally I do all) you need to change your URL to include the frontend. So it becomes something like "/clipperz2/delta/" for delta or "/clipperz2/beta/" for the beta frontend

Can you try that and let me know if it changes anything please?

[emroom]

Hi Graham,

Yes, of course, you are right. Now it works, I can create an account and login (did not try to create a password yet).

So I can undo the changes I made?

Thanks,

Edwin.

[aunxx]

Hi Edwin,

Yes, I think you can undo the changes. From memory, errors like that drop away when you access through the frontend.

Let me know if you have any more issues, but hopefully it should all be working for you now. :)

[aunxx]

Hi All, Python 2.7 has been deprecated, and as this was being used to build the php pages, it's stopped working on my system. I've updated the master branch (and tag to v1.1.0) of my repo, which now works for me to build the php pages using python 3. There may be issues still, so let me know if it doesn't work for you. This is purely a change to the build process, and not to any of the php/javascript so is functionally identical to previous tags.

Graham.

[LeoBolien]

Hi aunxx, my system is debian buster with installed python-git if i try ./scripts/build install --backends php --frontends beta i got:

_3.7.3 (default, Dec 20 2019, 18:57:59) [GCC 8.3.0] Failed to import git, please install http://gitorious.org/git-python Use sudo apt-get install python-git for Ubuntu/Debian Use sudo yum install GitPython for Fedora/RHEL/CentOS Or manually running the following command: easyinstall gitpython Traceback (most recent call last): File "/tmp/password-manager/scripts/builder/main.py", line 197, in main() File "/tmp/password-manager/scripts/builder/main.py", line 152, in main currentRepository = repository.repositoryWithPath(projectBaseDir()) File "/tmp/password-manager/scripts/builder/repository.py", line 28, in repositoryWithPath return result UnboundLocalError: local variable 'result' referenced before assignment

You must know that in debian buster python 2.7 and python 3.7 is installed but python links to /usr/bin/python -> python2

I found that some of the python scripts in scripts/builder have

!/usr/bin/env python

and others

!/usr/bin/env python3

after install apt-get install python3-git it works.

sorry for inconvenience Thanks Leo

[aunxx]

Hi Leo, I was just looking, and it seemed that python-git was version 2 only. I was trying to find out if there was a version 3 of that package when I noticed you'd replied.

Glad you got it working. :)

I'll go through and update the hashbang lines so they're all python3 some time over the weekend hopefully.

Graham.

[LeoBolien]

Hi Leo, I was just looking, and it seemed that python-git was version 2 only. I was trying to find out if there was a version 3 of that package when I noticed you'd replied.

Glad you got it working. :)

I'll go through and update the hashbang lines so they're all python3 some time over the weekend hopefully.

Graham.

I solve the issue by installing apt-get install python3-git

sorry for inconvenience Thanks Leo

[LeoBolien]

One more question,

i cloned by running: git clone https://git.whoc.org.uk/password-manager.git

Then i build (i use delta interface) by running: ./scripts/build install --backends php --frontends delta

When i made an diff between new and my existing version by: diff target/php/delta/index.html /var/www/clipperz/delta/index.html i see there is no real difference ony Clipperz_version

in Clipperz_version = " ad13fffb0727d3b1c6fe5f46944094b2d4b7bfaa "; out Clipperz_version = "b0423fad629ed6473f1e13067a81471389502d28";

My exiting version is b0423fad629ed6473f1e13067a81471389502d28

My question was there no change in the meantime, because my existing installation is from septemper 2019 ?

Thanks and regards Leo

[aunxx]

Hi Leo,

Yes, I've not made any real code changes in the new version. Just updated the build process to work with python 3. I had to move my web install to a new server, and it wouldn't build. I am not sure if there's been any updates to this repo which will need to be merged into mine.

Graham.

[mt-mrx]

Hi Graham,

I'm using currently a really old clipperz version, from the time when beta was the only frontend (maybe from 2011). I tried to upgrade clipperz to a new version in 2019 when I upgraded to php 7.3 but I failed so I kept a legacy php 5 setup for it around. Now I found this issue and your changed code (thanks for that!) in your repository and wanted to try again.

I cloned your repository and and configured it. That worked fine, I also created a new database and populated the structure using the setup and enabled Base64 encoding (because my old setup uses that as well). I can create a new user and successfully login using the "beta" frontend on this fresh and empty database.

But now I would like to migrate my old data. So I exported my old clipperz DB, cleaned out the new database and imported structure + data + routines from the old one. The "setup" shows the users and records I have, reports everything is ok. But I cannot login. I can create a new user and it is also created as new entry in the new database but even with that new user I cannot login, I only get an "Clipperz.PM.DataModel.User.exception.LoginFailed". My "old" user accounts have "auth_version=0.2" and "version=0.3" set. Further up you mention "Any old installs can be persuaded to work with some mysql changes though." which changes do I need to do?

Any help would be appreciated.

Thanks Matthias

[gcsolaroli]

Hello @mt-mrx,

to "migrate" your data, I would suggest to proceed in this way:

• verify that the new instance is fully working creating a brand new account;
• export your data in HTML format using the old application;
• import your data in a new account created on the new instance.

Hope this helps.

Cheers,

Giulio Cesare

[aunxx]

Hi Matthias,

I absolutely agree with Giulio. Whilst the database entries may be compatible, the user authentication mechanism isn't. Because of the way I had to change things to make it work again -- (the change was to SRP-6a I think) the old values just cannot be made to work. I've had some success with manually modifying the database, but I really wouldn't advise that. Safest options is to export, and import in HTML. I have tested that recently as I had to update an old version as well, and I can confirm it did work for me. Hope the new version works for you as well as the old one does, but any issues then let me know.

Graham.

PS: As an aside, if you do want to know about the database, from memory, the new version uses three entries to denote the user and password.There's a hash of the username, and the srp_v and srp_s values. I created a new user in the new interface, and then used the three values to update the old database. Again, I would really avoid doing this. Keep the databases separate, and export the old and import into the new.

[mt-mrx]

Hi @gcsolaroli , @aunxx ,

thanks for the tipp. Exporting and then importing worked. One strange behaviour tho, is the new clipperz version, tag: v1.1.0, enforcing password rules during account creation? Because one of my users had leading double quotes " in their password and that caused an "account creation failed" message even though a new userid was created in the database but without the sample card entries. I figured out if you don't have a leading special character in the password account creation works fine. Also if you create an account:

user: abcd
password: abcd1234

and then change the password to

password: "abcd1234

you only get a rotating progress indicator with the message "changing..." but it never completes. Afterwards I cannot login into the account abcd with neither abcd1234 nor "abcd1234.

Thanks

Matthias

[aunxx]

Hi Matthias,

I've never used single or double quotes in any of my passwords, so I would assume that there must be something wrong in handling those special characters. I don't know if it is in the javascript frontend, or the php backend, so I'll have to test. I'm not sure when I'll have time to try and fix this, but hopefully over the weekend. From memory, there wasn't a lot of input verification in the php code, so it may well be the backend that is causing the problem. Are there any errors in the php/webserver logs? Additionally the SQL code might be the area that is at fault. That may be the best place for me to start looking as I'd expect a failure in the frontend or backend not to break user authentication from an already working password.

Thank you for flagging this up. :)

Cheers, Graham.

[mt-mrx]

Hi Graham,

failing passwords are:

"abcd1234
!abcd1234
§abcd1234

Working passwords are:

abcd1234!
abcd1234"
.abcd1234
abcd"1234
$abcd1234

No errors in the apache error log.

When I enabled the mariadb queries log I get the following SQL statement when creating the user 'user: abcd pw: !abcd1234 ' where the user creation fails but since the SQL statement is executed the new user appears in the database.

           87 Connect   clipperz@localhost as anonymous on clipperz
           87 Query select `userid` from `user` where `userid`='' LIMIT 1
           87 Query insert into `user` (`username`, `srp_s`, `srp_v`, `header`, `statistics`, `auth_version`, `version`, `lock`) values (
            'c148a7fdf4f1f1732cdc90959cd34bf52e54cfd5e65d7bd7f341c3764a6d0166', 
            'fcbb2d002b7de46a8e200618273e09eddcb4f0dcf2aa20c10d9e7049980fda8c', 
            '86dbcf33b663d8b10f5124f72a3c38ea1923d81c1430459b074ea49c41c10395', 
            '{\"records\":{\"index\":{},\"data\":\"aaNp7zmTpOcYYD/fxMZ6EVKy\"},\"directLogins\":{\"index\":{},\"data\":\"oIl38cfZQOyK4E20gz/a6BgV\"},\"attachments\":{\"index\":{},\"data\":\"kshcHjcNygr9OBUWS1r6Z6L+\"},\"preferences\":{\"data\":\"ENQAQuop9IWlgb/MDEYZ516U\"},\"oneTimePasswords\":{\"data\":\"XN8b/QXN7/Tu2rOO6aJrE7cz\"},\"wallet\":{\"data\":\"WNNwPQrzo8tdNLloJ3YeQHm8\"},\"version\":\"0.1\"}', 
            '', 
            '0.2', 
            '0.4', 
            '')
                   87 Quit      

                   89 Connect   clipperz@localhost as anonymous on clipperz
                   89 Query     select * from `user`  where `username` = 'c148a7fdf4f1f1732cdc90959cd34bf52e54cfd5e65d7bd7f341c3764a6d0166' order by userid asc
                   89 Quit      

When successfully creating the 'user: abcd pw: $abcd1234 ', the following SQL statements are run.

           38 Connect   clipperz@localhost as anonymous on clipperz
           38 Query select `userid` from `user` where `userid`='' LIMIT 1
           38 Query insert into `user` (`username`, `srp_s`, `srp_v`, `header`, `statistics`, `auth_version`, `version`, `lock`) values (
            '8ed7a53629edeabae417ae1ef781eef8480888fef3baff69ad76abc8f010bc0f', 
            'd57487b78575f3f9f8e734c152bf21c03cb8fe663af818195f2a1911a57655a0', 
            '44e68265988dca8a4492d794ba029ece2183208b7041536357d0445d430875a0', 
            '{\"records\":{\"index\":{},\"data\":\"G93kZoNalI8dG0jNow6UJZNx\"},\"directLogins\":{\"index\":{},\"data\":\"jgyF1Y0oWcQ8bee+HAuBPJhS\"},\"attachments\":{\"index\":{},\"data\":\"4dIrfTUCvrmOoVPdyX744mBa\"},\"preferences\":{\"data\":\"ArOstPCAbcOS9y4ut+ahijsN\"},\"oneTimePasswords\":{\"data\":\"KQyuJERdVKAyPNMqgFRYWKVp\"},\"wallet\":{\"data\":\"uRMJ/rBYzWN4+RKZiLwiDqDf\"},\"version\":\"0.1\"}', 
            '', 
            '0.2', 
            '0.4', 
            '')
           38 Quit
                   40 Connect   clipperz@localhost as anonymous on clipperz
                   40 Query     select * from `user`  where `username` = '8ed7a53629edeabae417ae1ef781eef8480888fef3baff69ad76abc8f010bc0f' order by userid asc
                   40 Quit      
                   43 Connect   clipperz@localhost as anonymous on clipperz
                   43 Query     select * from `user`  where `username` = '8ed7a53629edeabae417ae1ef781eef8480888fef3baff69ad76abc8f010bc0f' order by userid asc
                   43 Quit      

                   44 Connect   clipperz@localhost as anonymous on clipperz
                   44 Query     select * from `user` where `userid`='73' LIMIT 1
                   44 Query     select * from `record`  where `userId` = '73' order by recordid asc
                   44 Quit 

Followed then by several insert statements into the record + recordversion table which I think are the 6 sample card entries.

Could it have something to do with my Table collation type of "utf8mb4_general_ci" or that I no longer use the Base64 encoding plugin? In my old installation I used "latin1" with the Base64 encoding.

And again, thanks for your work on the php code. ;-)

Matthias

[gcsolaroli]

Password values are NEVER sent to the server, so this should not be an issue introduced by the backend. All values (both username and password) are treated as array of bytes by the javascript code, so I also fail to imagine how special characters could cause issues in the frontend too. But I am obviously missing something here. 😕

@mt-mrx could you please verify if the same issue is relevant also on the "official" application?

[mt-mrx]

@gcsolaroli since I have no "official" version running, I cannot verify it. But I'm using the Delta frontend in Firefox and creating a new user with literally the user: abcd and password: "abcd1234 fails. I'm guessing you have a development instance running so it should be easy to reproduce if it is affected as well.

[aunxx]

Hi.

Yes, passwords are never sent to the back-end. I was thinking out loud, and what may have been the cause of the issue. :) I spent so long reading the srp requirements it is surprising it didn't occur to me what I was writing. :(

The information sent between the client and server are all hashes, or numerical values. Looking at the SQL, the same username should generate the same username hash, so something looks awry there.

I'll hopefully be able to test this over the weekend though.

Graham.

[mt-mrx]

@gcsolaroli I just created a testinstall based on: https://github.com/clipperz/password-manager.git I'm using commit "eb45334efecb66202898a216fb02800008a1d636" with

$ ./scripts/build clean install --backends php  --frontends delta
$ cp -a target/php/* ~/clipperzdev.example.de/
$ cd ~/clipperzdev.example.de/; ln -s delta/index.html; ln -s delta/manifest.appcache

Tables inside the test database are created as MyISAM/utf8mb4_general_ci. I'm not using the Base64 plugin. (I also tested latin1_general_ci and latin1_general_cs, same behaviour) I've setup php 5.6.40 for this virtual host to use.

Registration fails for:

user:     password:
abcd     abcd1234
abcd     "abcd1234
abcd     $abcd1234

I see that new user entries are created in the database "user" table. And there for every try, as long as I use the same username the username hash is identical.

However I always get a "registration failed", so if I'm using the official version I wasn't able to complete a single registration succefully.

@aunxx I just rechecked your version and when I use (1) user: abcd and pw: !abcd1234 and (2) user: abcd and pw: "abcd1234 both registrations fail but I get two new entries in the DB with the same username hash. However when I use (3) user: abcd and pw: abcd1234 and (4) user: abcd and pw: abcd12345 both registrations succeed and I can login, then the resulting username hash in the database is different for both users. So username hashes (1) = (2) != (3) != (4)

cu

Matthias

[gcsolaroli]

@aunxx your assumption that "the same username should generate the same username hash" is not correct; the username Clipperz send to the server (also known as the SRP C parameter) is not and encoded version of the username, but the value is 'salted' with the password. This make possible to have multiple users with the same username, obviously using different passwords. We did so in order to NOT being able ourself to look up user data into the DB knowing their username.