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

The Gallery
1

Project URL: CONFIDENTIAL

You wouldn’t believe how many people can’t make a simple login system and have to resort to using a bad and confusing external service.
HTML DB is a site where people can register a login DB for free and use it effortlessly in their code.
The devs can also see who has registered while also being cabable to ban people who abuse their site.
HTML DB is currently in bad need of an update, which means developers who help code and contribute to it.

DM me or @Jonyk56 if you’re interested in helping with HTML DB.

Thx,
DerDer56

4 Likes
2

ANOTHER COMPETITION EH?

begins work on update for html-db

1 Like
3

Wait you have a database system?

1 Like
4

yea, html-db.

quite old, and doesn’t work properly now-adays, needs an update badly

1 Like
5

Ok, cool. R u interested in Log DB

1 Like
6

maybe, i could use some of my skills to help ya, u got discord?

1 Like
7

When you say:

Does that mean the passwords aren’t hashed (and salted), as I would never ever ever use a login/signup system with a db while not hashing (and salting) the password. Anyone who could get into the db (e.g. with brute force) could see the passwords

5 Likes
8

You should not let devs see the passwords. That would be a horrifying idea for the visitors, and would be for the devs. Hackers can just swoop in and steal the passwords which would result in less visitors.

5 Likes
9

The data will be hashed and salted. Only the site creator can see the data and only the site creator can register (you have to append a certain piece of code to your home page) to be registered.

1 Like
10

What’s the point of showing them the data if it is hashed and salted? They won’t be able to make anything out anyway. Just let them ban visitors and leave it be. Don’t need to give them actual access the DB

4 Likes
11

But if its hashed no one can see the password

1 Like
12

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

2 Likes
13

Why do I have to share this again, and again?!

11 Likes
14

=|

1 Like
15

I’m getting confused here, why does the title of this thread say “HTML DB”?

4 Likes
16

I don’t think developers can trust you with all the hashed passwords for their projects.
Even if they’re hashed, a data breach can have horrible results. If people signed up for the developer’s service using basic credentials - they could be decoded.

1 Like
17

Yes, an oAuth system is safer to use, where you do not have to worry about passwords. :sweat_smile:

1 Like
18

Good ol’ Tom Scott.

4 Likes
19

Indeed, I’m a big fan of his, he has a lot of videos about CS theory. And of course other stuff.

3 Likes
20

I love The Park Bench with him and Matt. He said once on there that he only learnt to code to get a well-payed job whilst he was working on his languages (not coding - like how people speak and stuff :joy:) at university. He likes his speaking stuff much more than his coding. I find that really interesting :slight_smile:

3 Likes
21

the database package is coming along very well! We decided to instead of make an entirely new database package, to branch off of an old project which we all used to know as html-db ( which is still named that, but, that was solo me ), so, progress is going good on this!

1 Like
22

You put a HTML form on your page with a post request pointing to there site and they store/authenticate passwords.

But they are saying devs can view passwords, so are you guys one way hashing? That shouldn’t be possible with 1 way hashing…

3 Likes
23

They confirmed they were giving up on allowing devs to see passwords, hashed or not, after I and others pointed out it was a huge security risk

3 Likes
24

We may still do it, the web side of things is the only difficult part of this huge project, and the only reason why it is huge, is because of the web side of things

1 Like
25

May still do what?

1 Like
26

allow devs to see passwords

1 Like
27

NOOO don’t allow devs to see pwds

1 Like
28

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

1 Like
29

Hashed or not?

1 Like
30

What purpose would it serve to allow developers to view passwords? It pointlessly weakens the cryptographic model.

Use bcrypt. That should be the end of the story.

7 Likes
31

depends

1 Like
32

But anyone could get into the devs account by guessing their password! It should be against the Glitch ToS to not hash passwords, it’s really simple and not doing it is just a security risk

1 Like
33

Yes @RA80533. bcrypt is really easy and you can hash the password by just doing about a line of code that you can just copy from the npm readme! Simples! :slight_smile:

1 Like
34

Remember: when you deal with encryption, you’re dealing with munitions according to U.S. law (see this thread). You should respect its implementation accordingly.

4 Likes
35

Remember this though:

4 Likes
36

https://github.com/Jonyk56/html-db-official/ well, here is a little precursor

1 Like
37

I suggest that someone from @glitch_support closes this, if the OP want to store plain-text passwords go ahead, I’m not using this, I doubt others will too.

7 Likes
38

=/, it is web/server only/client only, the thing is universal, this part will only be for web…

1 Like
39

This is a major security vulnerability and should be shutdown. Projects that are openly storing plaintext passwords are a bad idea.

4 Likes
40

:man_facepalming:

It won’t be openly storing them, lordy, is it this hard to get a point through to some of y’all?

we don’t have all the plans figured out yet, but YES, they will be encrypted, NO they will not be easy to acces, AND NO! openly storing anything sensitive is a dumb af idea, I’m not dumb to let it slide by in any project i’m involved in

1 Like
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
61

data recovery, and plus, every management system needs an admin account, so, technically, this is that admin account, but instead, just a key to manage everything

2 Likes
62

What you would do instead is just allowing the user to request a password reset, you simply don’t ever store the user’s password in plain text or encrypt it. Even just hashing isn’t good enough. You should hash and salt. All other ways of storing passwords are naive and insecure approaches and just should not be used.

3 Likes
63

I would look into using this for more non-sensitive info (maybe for less secure forms).

I would just like to see better docs to make it more friendly towards newer users.

2 Likes
64

that is exactly what it should be used for, more or less, private things/ large projects, using it server side only, and not served as a web page for large things, it has multiple combinations…

server side only ( recommended for starter projects )
server side + database management ( private projects )
server side + client side ( private projects/large projects )
client side only ( large projects )

also, docs are being developed, i am with taking the slow time consuming task atm

1 Like
65

Passwords should not be stored unhashed, let me put you through this scenerio.

  1. We can agree that people tend to use their password on most of their stuff, for instance, a person might use the same password on Youtube, as they do on their email account. Let’s be honest, you probably also do the same.

  2. We now have established that most people use the same password across multiple places.

  3. A sudden glitch server administrator decides to go rogue, they just access your project with no implications what so ever. They find your encryption key within seconds, they now have a database with a lot of encrypted passwords, but since this rogue system administrator has the key, they decrypt all the passwords. The rogue system administrator now has all the passwords.

  4. He tests all the passwords and users and etc, and he appears to have found a google account using the same credentials, this is just after 10 minutes of getting access to your project, decrypting the passwords and testing a few accounts.

  5. He realizes that the google account has a credit card linked to it, he saves this account for later use.

  6. He continues to test usernames, emails and passwords, and he now has a lot of personal information, all because of how you stored the passwords.

You shouldn’t just assume that just because only you have access to the key, your system is secure, it isn’t. If you do just one small mistake, it can be at the cost of others. I consider the fact that you don’t take security seriously as disrectful upon the users who use your services. And it makes you plently less trustworthy. Just saying.

8 Likes
66

While this is an extreme scenario, it could definitely happen.

I personally just feel a lot more comfortable knowing that my passwords cannot be access.

5 Likes
67

:expressionless:

1 Like
68

it could happen, a datacenters admin got into a nordvpn server before iirc

2 Likes
69

:expressionless: ok, i will think about maybe changing it up, but we still will aim for the ability to see passwords, reee

1 Like
70

that’s still a massive issue

2 Likes
71

If the case here is that you don’t know how to implement a login strategy here is an example.

const { hash, test } = require("ihacks-hash");

function registerUser (username, password)
{
    const user = { username, hash: hash("sha512", password) };
    storeUserInDatabaseSomehow(user);
}

function loginUser (username, password)
{
    const user = getUserFromDatabaseSomehow(username);
    const isPasswordValid = test(user.hash, password);
    if (isPasswordValid) return user;
    else return null;
}
1 Like
72

I’ve seen/known of many companies that have done this and 80% of them have been breached

6 Likes
73

hmmmmmm, looks promising, we MAY use it, so, maybe…

1 Like
74

And most of them used VERY STRONG AND ADVANCED ENCRYPTION, which is something I doubt you know much of, sorry.

P.S. I’m not trying to be rude, I’m trying to point out the fact that passwords should be treated with utterly respect and measures of security. Encrypting passwords is just something you don’t do. Think of it like this, would you like me having a picture of your credit card details (if you hav any)? You don’t know what I do with it, but I have them and can share them worldwide if I feel like it. That wouldn’t be fun, would it?

4 Likes
75

:expressionless:

1 Like
76

Simply don’t store plaintext/encrypted passwords anywhere.

5 Likes
77

I’m not saying that will prevent a possible breach but it will make it a lot more difficult

2 Likes
78

let’s be honest, vulnerabilities will always exist but its always the best idea to try to prevent them from happening

3 Likes
79

I am saying this for the last time,
WE will not be showing user passwords.
We will not change our decision

1 Like
80

also just as feedback I think many people would rather use their own login systems rather than using someone else’s where security cant always be guaranteed.

Edit: also if lets say i had my own login, I could fix it as soon as I found an issue or if a hired professional found an issue. With a database like this you will have to wait for the dev to fix this error and hope that your site wasn’t impacted.

4 Likes
81

Won’t using an oAuth system solve all these problems?

82

Yall should see the amount of cases at

https://haveibeenpwned.com…

and see that they are 100,000!? pastes.

1 Like
83

Funny thing, I’ve developed a habit of entering random emails into it, try entering [email protected]

1 Like
84

[email protected] have been pwned.

image
image964×397 128 KB

85

It mentions Elasticsearch but glitch uses Agolia. It could have been someone who thought it’d be funny to use glitch’s email to sign up for a service or the person who owned glitch.com previosuly

2 Likes
86

Not relevant I believe, it says that the email address was included in the breach?

87

we can just go to your profile and find the project url… just sayin

88

Not really, we have private projects otherwise you could easily copy other people’s discord bots

89

i said url not source

90

and the project they are using isnt private, do your research before saying that.

91

GLITCH HAS BEEN PWNED???

@glitch_support here ya go…

92

That wasn’t really worth pinging I think

2 Likes
93

Hold on. Is your project aiming to be, more or less, a keychain library? If so, you should’ve made it clear from the start that it’s explicitly for third-party credentials and would not be used as authentication in any way. I’m hoping that’s what you meant to describe it as.

94

If this however is a keychain library they should’ve used asymmetric cryptography to store passwords.

1 Like
95

I believe that’s what the user was referring to by noting of the master password, etc. Still, it’s quite easy to have a vulnerable implementation of such a library.

2 Likes