Hi Kelvin,

How do you change the Logo?

Steps to reproduce

• Generate a password with a number of views greater than 0
• Access the page every time until the "last" view before deletion - All OK
• On the "last" view before deletion, "True " is appended to the password in the box. i.e. - "True VerdureGemmateHalesia)!=54"

Removing line number 32 in AzPwPush.psm1 resolves the issue

Admittedly, this issue is user error, but if a user passes in a Password parameter and does not correctly escape a "=" sign, the current method of grabbing the password value, will only grab everything to the right of the last "=" sign. This could cause serious, unintended consequences. There is already a separate issue for the not allowing passing of a password as a GET parameter.

Password Pusher has a cool feature where you can restrict a password to X number of views before it is deleted (otherwise it will delete after X days). I think this would be a nice feature to add. It would probably require changing the password storage format to a a JSON string with a "NumberOfRemainingViews" attribute as well. Again, I will implement this in my branch, and would be happy to include a PR at some point, if you are interested.

When we try to create a password, random or own created password. The Get URL shows nothing in the password box.
Any ideas how we can resolve this?

I can see a couple of uses for this and wanted to check the demo version to see how it looks.

Using the demo version you posted online the get password doesn't have a password shown in the browser (Modern Edge beta) at https://pw.cyberdrain.com/Get?ID=12345678 (where 1..8) is a unique number generated previously.

The only thing stopping me from using this immediately was the need to purchase an SSL cert

I'll probably implement this in my own branch sometime this next week, but I think a /Delete endpoint would be nice, and a link to that on the /Get page, so that a user can delete a password after retrieving it and not leave it lying around for 5 days or whatever if they don't want to.

Admittedly it is unlikely, but conceivably the same random number could be chosen twice in a short period of time. In such an instance, the current code would overwrite the existing password with the new one. This could result in leaking a password to the wrong recipient. Please consider catching this case and generating a new id (also see separate issue on using GUID instead). I will be forking and adding/testing fixes for all the issues I just reported, in the near future. Thanks for this great starting point.

Azure functions can go idle and restart when they are requested on the consumption plan. DPAPI does not always work after wake. I suspect that the function wakes on a non-windows host which does not have the DPAPI.

Moving away from DPAPI seems like the step to take.

Security wise, the form should do a Post and the URL should not contain the password in clear text ever, for 2 reason.

1. Browser history
   Password is saved in clear text in the browser history.
   

2 User (Code 18)
If the user give the url from the address bar instead of the url in the form.
(eg: I do sometimes that by mistake with Onetimesecret.com ), you end up giving the actual password in clear text and it will never burn.

Using Onetimesecret as a reference,

1. The form is a Post
2. The return url is an ID unrelated to the secret.
3. There's a button click to view & burn the secret from the #2 location (So that even if you give the private url away, the password is burnt as soon as it is viewed anyway.

I feel terrible, since I suggested moving to GUID's for ID's. GUIDs are guaranteed unique, and as of UUID Type 4 which is what the New-GUID method in Powershell uses, they are not directly tied to the network MAC address, however, they are seeded largely from values that are known, or could become known to an attacker. Should an attacker know when a password was generated, they can conceivably narrow down possible GUID's to a fairly small range. The consensus is that UUID's are not unguessable and should not be used for passwords (or things that lead to passwords): https://stackoverflow.com/questions/643445/how-easily-can-you-guess-a-guid-that-might-be-generated

I know we are moving into the theoretical here, but it might be good to additionally add 8 hex bytes from a CRNG to the end of the string with something like this: https://github.com/virtualox/Get-RandomHex/blob/master/Get-RandomHex.ps1

The above change should ensure that the ID is unique, un-guessable, and long and unique enough that it cannot be enumerated even by an attacker with significant information about the environment that it runs under.

For ease of use it would be great to have a "Copy URL to clipboard" option

Password URLs pick a random URL number between: 1 and 999999999999999. This can result in very short URL's that are easily enumerated. Given that there is no rate limiting there is a pretty decent change that an attacker could successfully enumerate a password in a reasonable period of time. Please consider something like [guid]::NewGuid() instead for the ID.