You don't have to worry about the security of storing the session ID in the database backend. That's not where it is usually at risk. Your server is, hopefully, secure. If it isn't and an adverary can somehow access the database you're running on it, you've already lost because then all the information you want to protect using a website login is probably known to the attacker whether he has access to the session id or not - chances are he won't just be able to access the database, but all the files on your server that the webserver has access to. Unfortunately, this includes the data you actually want to protect with your login.
Usually it's the client and the transport medium that poses much bigger security risks to the session.
Others have mentioned how important it is to use an encrypted connection. I agree. Making your authentication secure without https / TLS is very difficult.
Not encrypting your connection leads to the browser cookie being sent over the wire in the clear. So it doesn't make sense for you to worry about the 100-character code being stored securely in the database; it's much easier to get at this code by simply reading it out of the cookie while the cookie is in transit.
If you don't want to use https (lets encrypt is a very good suggestion imo), you should first secure the cookie. This is arguably even more important than taking care of sending the password in encrypted form, because while the password is only transfered a single time - at login - the cookie is transfered with every single request the client makes to the server, and thus the chance that it is stolen is greater (though the consequences of the password being stolen are probably worse).
You could make your cookie more secure, for example, by sending back a new cookie with every response and have the cookie consist not only of your secret 100-character session id, but instead add to that a nonce and build an hmac over both the session id and the nonce using a secret only the server knows. Then if someone steals the cookie from the request, that won't do him any good because it won't be valid for a second request. And if he steals a fresh cookie from a response and uses it before the legitimate client does, the server will notice something is wrong when the legitimate client tries to send a request using the now-used-up cookie.
If you don't encrypt your connection and don't add a nonce to your cookie, you'll always be susceptible to replay attacks for the lifetime of the session.
By the way, since you're saying that the only reason you need the authentication is to authenticate a user, not to give him access to personal information stored in the database, you could get away by simply storing the username of the logged in user, the date he logged in and a nonce in the cookie. Encrypt the cookie on the server using a secure symmetric encryption algorithm. If you do this, you don't even need to store any session ids in a database; you can see whether a client is authenticated by simply looking at the decrypted cookie. This isn't any less safe than session ids if you keep the cookie encryption key secure on the server, and if you can't do that, well then you probably can't keep the database on the server secure, either.
As for the plaintext password: Note that encrypting the password using Javascript in the Browser doesn't actually help very much, it just looks more secure. The problem with that idea is that what you should be protecting yourself from is a man in the middle attack, e.g. someone listening to all your traffic, usually by sitting somewhere on the route from the client to the server. Someone who has this capability can probably also make arbritrary changes to your traffic; e.g. he can always change the javascript encryption routine to his liking. Javascript is not a secure platform: What if he changes your state-of-the-art encryption function to this:
function encrypt(password) { return password; }
You mention that you've looked at Auth0 as an alternative to rolling your own authentication method. If you don't use https to secure the transmission of your passowrd, then I don't think you can do it in a secure way at all, and looking at third-party solutions would be the right thing to do. You could use digest authentication, which is provided by Apache servers and which is a bit more secure than sending your password in plaintext. But I'd suggest you look at OpenID Connect, which is a lightweight authentication solution built on top of OAuth. It basically consists of redirecting your user to a login url provided by one of the OpenID providers (Google, Microsoft, Twitter, Yahoo, ...), then receiving an answer on an endpoint you provide as a callback. It's much simpler than you'd think and both Google and Microsoft have step-by-step instructions on how to set it up, plus code libraries if you want to use them. I think this is secure even if your oauth callback endpoint uses http instead of https (but I may be wrong, check before blindly trusting my memory). OpenID may be overkill if the login system is just for yourself, but it's also not much more work than implementing your own login/logout functionality and probably much more secure than rolling your own solution.
Finally, if you don't use https, you make all the not-for-the-public-eye stuff on your website visible to a man-in-the-middle who watches your clients access it. After all, all this secret data is transfered in the plain. There's no way around that.
Best solution to that: Go with shackledtodesk's suggestion and get a let's encrypt SSL certificate.
