I am studying about hashing/encrypting databases, but i have a question:
Lets suppose a app, what you can create a account, and save notes in your account, like Evernote. When you login, your password will be compared with the saved password (Bcrypt), and if your password is correct, you can login.
But, how we can encrypt/hashing the notes? because notes will be catched with a GET or a POST what will only have a Authorization header, how can i encrypt/hashing the notes table, and decode this data? And what algorithm do what i want?
OBS: I am using Node.JS for Backend.
Sorry if this question seems dumb.
Related
I'm building a system, where its registered users are able to send emails automatically. I came across 2 solutions to achieve this,
By getting the username and password of GMAIL accounts and sending mails using nodemailer.
By using Google Oauth, to let the users give access to my app to send mails on their behalf(Without sharing their mail credentials).
The first method works as a piece of cake, but the second option sounds a bit more professional and safe. I figured out how to send mail using a single acc. to other people. But couldn't find a possible solution, to send emails from the user's mail. (As it requires refresh token to send them)
I came here looking up for a possible solution that helps me solve this issue.Thanks in advance!
Go with google OAuth or if using first one use bcrypt salt or some type of hashing to secure password.
I would suggest you to go for second option. There is a good and very important reason to do so. You need to have a good and secure DB to save this information which could be an overhead for you.
Hashing the password and saving it to the DB won't help you. As you can never get the actual password from the hashed one and you can't send the hashed password to the gmail account. So, you can't do that.
Second option is a better way in every term, you just need to have a refresh token and that won't be a big deal. You can get it nodemailer transport layer can help you to get it.
I am attaching this link where you can easily replicate the steps to get it done.
I've spent the better part of the day trying to figure out how OpenID works. My goal is to set up a simple site where, upon clicking a login button, users are taken to a Steam login-page, where they are prompted for username and password. After successfully logging in, the user is redirected to a page on my domain, where I collect the query string parameters. They look like this:
{
"openid.ns": "http://specs.openid.net/auth/2.0",
"openid.mode": "id_res",
"openid.op_endpoint": "https://steamcommunity.com/openid/login",
"openid.claimed_id": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.identity": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.return_to": "http://127.0.0.1:8000/resolve",
"openid.response_nonce": "2018-12-01T14:49:46Z30hhn2/[someTEXTendingIN=]",
"openid.assoc_handle": "1234567890",
"openid.signed": "signed,op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle",
"openid.sig": "[someTEXTandNUMBERSendingIN=]"
}
What I am unable to solve though, is the actual authentication issue. I'm not sure what to do with this data. I want to have my own database where I store more information about the user, such as friends, messages, currency etc. For this, it is very important that I can verify that someone didn't just take this request body, change their ID for another and in that way access their account.
I'm pretty sure these are the relevant pieces of documentation, but it still isn't clear to me. How am I supposed to authenticate the user with this data?
I've omitted some values in this post that I fear could be bad to share. These placeholders have been outlined with brackets []. Also, that assoc_handle is really 1234567890, which kind of puts me off, since according to the OpenID documentation, it is used for determining the signature.
To be clear: this page where credentials are collected is not run by me, but is the official OpenID sign-in page for Steam. Steam is a gaming platform. https://steamcommunity.com/dev/ for reference.
For Steam authentication in nodejs you can use Passport.
Passport is an authentication library that works best with Express-based web application.
There is a steam-strategy that can handle your steam authentication.
Check passport here
And this is the Repository for Steam strategy. There is an example folder that you can see how to setup your Steam authentication.
Im trying to understand how a user can keep logged (i'm trying to implement this on Node without frameworks, for learning). Just a couple of questions based on what i think i understand:
(1) When the user tries to login, it sends the user and password in an HTTP request body
(2) When data arrives to the server, it checks everything needed like if the user exists and if the password is correct
And here comes, i think, my problem: How can the user keep logged? The third step would be something like:
(3) The server create all the session data needed, encrypts and send it to the client?
(4) The clients store the encrypted data in the localstorage
(5) The credentials are sended with every request to the server, and the server decrypts it and check it before processing every user's action.
That's what i understand. But i find this very extrange. I feel i missing a lot... storing data in client side doesn't seems (at least for me) secure. Should the session data be stored on server-side? And how the username and password should be sended securely? It must be encrypted client-side? Is this secure? I think im looking for some pattern or i don't know. I feel lost.
Yeah, and sorry my bad english and poor knowledge. Im not asking for code and i will also appreciate any hint (like what to search in google, or a interesting blog) :)
Thank you, y un abrazo :)
--- EDIT ---
Well, finally i founded some usefull links and solved great part of my doubts :)
[http://stackoverflow.com/questions/6922145/what-is-the-difference-between-server-side-cookie-and-client-side-cookie][1]
[http://blog.codinghorror.com/protecting-your-cookies-httponly/][2]
[http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf][3]
[https://es.wikipedia.org/wiki/Cookie_(inform%C3%A1tica)][4]
[https://newspaint.wordpress.com/2015/09/06/how-to-get-cookies-from-node-js-http-response/][5]
1 and 2 are correct.
Sessions are usually implemented using cookies, not client-side local storage, because cookies are automatically sent to the server with each request. The cookie will often contain just a long randomly generated ID which refers to data stored on the server side, e.g. in a database. This data will identify the user and possibly store other session-level settings.
It is also possible to use a cookie with signed (and possibly encrypted) user information - for instance ASP.NET does this by default. This has the benefit that no storage is required for the session. The downside is that sessions cannot easily be destroyed from the server side. Therefore e.g. a feature that shows the user their currently active sessions (from other devices) and allows them to log them out couldn't be implemented.
Sending the username and password over the Internet should preferably be done securely, by using HTTPS. Do not implement your own encryption on the client-side. It will likely not work, plus the cookies themselves are viable to be stolen if the connection is not properly encrypted and authenticated.
I am working in a project and actually the first time using nodejs, express and mongodb. For the authentication i am using passport.js which look pretty flexible and easy to integrate it.
I really like the idea of Serializing and Deserializing but my concern is about the user object which is always ON and can be used on every request.
My project involve subscriptions, user profile and maybe a small ticked system.
So my user schema it contains user credentials, user info like address, phone, email and also information about the subscription. Some of this information is embedded documents with in same schema. It seems weird that all this info is always ready even i do not needed, even the bcrypt password is always on the request call.
My question is, do you think is best practice to separate the user credentials from the user object and play with relationships soi can call the user info when i need it with normal controller model way?
Thanks in advance
if you are referring to sessions you should really only be sending a small piece of data with the request such as a user id. The entire user document should not be going across with every request.
It's common practice to separate user credentials from the rest of the user data, because the credentials need to be stored in a very secure manner - so much so that it dictates different infrastructure.
I work at Stormpath and we provide this as a service. We store the password for you, with very high levels of encryption. We have a great integration for Express, you check it out here:
https://github.com/stormpath/stormpath-express
Is it better (more convenient or secure) to provide users with a lost username or password via direct message on Twitter rather than via email?
You don't supply lost passwords at all (mostly because you can't, because if you're doing it right you don't store passwords in plain text anyway).
You facilitate a reset-feature that allows the user to, with the help of for example a secret question or simply an activation link via email, change their password.
I really don't want sites throwing my username and password over Twitter.
No thank you!
It is as secure as sending it over email. If you generate a new password and then send it to the user via dm only the user can read it. And yes the user can access twitter in an unsecure way over an not encrypted connection. But you can't assure that somebody uses an encrypted connection to access his mail either.
In fact it could be more secure because you know that only twitter admins can intercept the message and no admin reading the mails from his users
Security aside, there's also the significant flaw that you can't send password reset information, password reminders, or anything else to your user via direct message if he's not following you on twitter. Unless your site is itself a twitter client, then the odds are pretty good that a substantial fraction of your potential users won't be particularly interested in following you and are likely to resent being told that they must follow you (or at least follow/change password/unfollow) if they want to use your site.
Update: I forgot to mention... If you want to tie your user authentication functionality to twitter, then why not just use Twitter OAuth instead of maintaining your own password store at all? It works quite well (barring the fail whale), is very quick and easy for the users, and doesn't place any requirements on who they follow or don't follow.
Start by reading this post: What is the best “forgot my password” method?
This will get you started in the right direction.
I want my password sent by UPS, FedEx, or USPS when I forget them.
Punish the user.
Bad user.
Enough people have pointed out that you shouldn't be storing passwords in plain text anyway, so I won't repeat that.
But if you're sending a one-time-use password-reset link as a Twitter DM, then you have to take into account that the user might receive that message on their mobile phone.
Then you'll have to make sure whatever that link points to is set up to display correctly on mobile phone web browsers.
Then you'll wish you just stuck with email.
Secure your passwords and don't send anything by email or twitter. Lookup MD5 and other algorithm to do this.
Wikipedia says:
In cryptography, MD5 (Message-Digest
algorithm 5) is a widely used
cryptographic hash function with a
128-bit hash value. As an Internet
standard (RFC 1321), MD5 has been
employed in a wide variety of security
applications, and is also commonly
used to check the integrity of files.
I hate it when I see a website storing my password without encryption... and if the website started sending me my password via twitter I'd break something.
Instead of sending passwords verbatim over any insecure channel, send a nonce instead. Such as: a one-time URL the user clicks, verifies personal info, then is forced to choose a new password.
This way, if the message is intercepted, no damage can be done without also hacking the personal questions.