HTML DB / An easy-to-use database for devs to add a secure login/password system to their site

The Gallery
41

Erm. Did I miss the msg where you said you won’t be doing that?

2 Likes
42

ofc, there will be security if we do implement this, most likely an off-site master key that a generator must make

obviously, they can see the passwords, but they will be encrypted

1 Like
43

Why?
How does it help the dev if they can see an encryted password that they can’t unencrypt.
And if they can unencrypt thats a problem.

2 Likes
44

off-site master key

I am planning AES-128 for the passwords…

1 Like
45

I just feel wayyy more comfortable knowing my info cannot be accessed…

5 Likes
46

What @DerDer56 said still stands:

Ok I agree and think it would be smarter for them to just see usernames and block users

We will not be implement anyway for devs or anyone to veiw passwords. They may only veiw user names and block users for abuse.

3 Likes
47

tell us about how you came to choose that, because we enthusiasts aren’t satisfied if you just pick any old crypto algorithm

5 Likes
48

we will not be showing user passwords and that is final @wh0

2 Likes
49
  1. because aes is a very small algorithm
  2. html-db was originally made for efficiency and small size, so, naturally, aes-128 is a good choice
  3. if you didn’t understand, go back to 1 and 2

@idodev the passwords can be accessed, but yet again, only decryptable using an off-site master key

1 Like
50

Thanks for posting why you’ve selected AES-128.

Would you be willing to talk about the details of how HTML DB integrates the off-site master key? Because a number of issues make that tricky:

  1. making sure that off-site service that holds the master key has good availability so someone can use HTML DB to sign in at any time
  2. preventing the developer from accessing that key, or ideally for no one at all to be able to access the key
  3. backing up the master key or otherwise can’t easily be lost
  4. how the off-site service authenticates the app that needs to process a sign in attempt
4 Likes
51

HOW TO STORE PASSWORDS

Client

  1. Collect the user’s input.
  2. Check the strength of the user’s password.
  3. Check if the password has been included in a breach.
  4. If both of the above was okay, send the password to the backend server.

Server

  1. Receive the user’s input.
  2. Generate a random salt.
  3. Select a strong hashing algorithm. (sha512)
  4. Combine the user’s input with the salt. (salt + password).
  5. Hash the combined data.
  6. Combine the hash with salt. (salt + hash).
  7. Store the hash in the database
5 Likes
52

We alreaady have partially planned this out, it will interact with an off-site api that stores all of these keys, and whenever html-db is downloaded, it will reach out to this api, and generate a key, the key will be saved on the api, and then be given to the person who install html-db once and once only, they can generate a new key by re-installing html-db, and that about wraps it up…

almost forgot to mention, we do have a w.i.p. site where you can access all keys, but that is not yet done, nowhere near in fact

1 Like
53

hibp v2 has been discontinued, link v3

1 Like
54

The part where it gives the key to the person who installs html-db would be subject to the same complaints people had against letting the developer see the cleartext passwords. In the design you described, the site owner/developer/person who installs has access to the encrypted passwords and the key, which would allow them to decrypt and view the passwords.

4 Likes
55

Here’s my module I just made for hashing. I recommend using this because it is idiot simple. Meaning that any javascript beginner should be able to use it without issues.

In other words, the module is idiot proof.

3 Likes
56

is it reversable?

1 Like
57

No, a hash is a one way function. You cannot possible ever extract the information my module produces.

2 Likes
58

welp, then we can’t use it, best to make something 2 way

1 Like
59

I think with the test function you can still compare an input with the hash, just not extract the data from the hash

1 Like
60

Why would you ever want to know the users password? That is a major security risk.

Let me tell you something that actually happened:

A couple of years ago, Adobe did the exact same naive thing, they encrypted their passwords. What happened is that their database got hacked, and then a bunch of hackers leaked everything. So now a bunch thousands hackers and programmers have a HUGE list of encrypted passwords and their password hints.

Story short, over 10GB worth of passwords was leaked. Think about that before you publish this.

7 Likes