Hello to the whole community. :)
I am currently working on integrating moodle for an e-learning platform. I have implemented most of the functionalities using web services (Javascript Client). But, unfortunately, I find that the web authentication service does not exist.
I said to myself, for authentication at the level of my system without redirecting the user to moodle from the information in the moodle database, I retrieve the password from the login and I test with the data entered by the user but the concern is that the core_user_get_users and core_user_get_users_by_fields functions do not send me the password (encrypted) but just the other information.
Need your help !!
core_user_get_users and core_user_get_users_by_fields are, quite correctly, incapable of sending the user's password, because Moodle itself doesn't know what the user's passwords are.
Moodle only stores a one-way hash of the user's passwords - each time a user logs in, the hash of the password they entered is compared with that in the database and the user is allowed in, if they match. By design, it is very difficult (and time consuming) to start with the hashed password in the Moodle database and figure out the user's password.
If you need a mechanism for logging a user in to Moodle from your system, without them having to enter a password, then you should consider using a Moodle authentication plugin that supports Single Sign On - the standard Moodle authentication plugins are listed at: https://docs.moodle.org/en/Authentication, but you may find that there is a 3rd-party authentication plugin that helps you at: https://moodle.org/plugins/?q=type:auth (https://moodle.org/plugins/auth_saml2 is often a good place to start).
Related
I realize that there are other posts on Stack Overflow asking similar questions, and the answer is to NOT to store passwords in local storage, but I need to. If there is a better approach, please let me know.
I am building a password manager. I am trying to develop it to work mostly offline. The way it works is that the user stores their "vault" on my golang web server. The server is only ever accessed when the client or server needs to be updated. So: the user logs in, the vault is sent from the webserver to the client, each time a password entry (username, password, name, etc) is created, each aspect of the entry is encrypted using the user's "master password". Since I would like the webapp to be able to work offline, I need to store some version of this master password in local storage or as a cookie (preferably as a cookie). I would like it to work similarly to other password managers, so if anyone can provide some insight on how they approach this problem, please do.
What is the best way for me to store the master password locally? I would like my approach to be as secure as possible. If there is a different approach I can take, I would love to know. My main thing is that I need the webapp to be able to work offline.
Please note that I am not using node. If I can provide any additional information, please ask.
Thank you!
The best way is to (as everyone is saying) NOT save data locally. That is a huge security issue. Other thing is that a Website can not be offline (unless its a PWA), so running the website offline is never gonna happen (Unless you create a PWA).
My Suggestion is that if you want to make it work offline you can create Chrome extension and use chrome.storage API for storing Encrypted password ( storing plain password is not recommended ). Even with web extension, it is not advisable to store password locally.
You can make it work offline if user is logged in and but not connected to internet anymore and browser is still running. Every time user open browser after closing it, you should (always) authenticate user again.
1). Since you are encrypting vault using plain master password, you can use any encryption/decryption method to encrypt master password ( which will be stored using api ) and to decrypt the stored encrypted password ( decryption is required as you will need plain master password for verification ).
Hashing algorithm is not a good option here, since hashing is one way encryption and depending on which algorithm you use you can have different hashes for same string.
2). Yes, you can check storage.local browser compatibility here
Electron can help you to develop what you want. With Electron you can develop offline app's to any S.O.
And you only need to know about HTML, JavaScript and CSS.
Take a look at official website
Today a lot of apps are made using Electron, like VS Code, Slack and a bunch more, look at this link: App in Electron
And if you really want to test, do a simple app following this Tutorial.
To store your password locally you can do a encrypted key and concatenate the machine info to make part of the password.
For example:
You can get programmatically machine MAC Address +
And do a simple and less secure MD5 encryption, and you will get something like this: e99cde2308fb2ff5612f801c76b18f6c
In the world exists a lot of encryption manners.
Good luck.
I've a requirement to integrate Auth0 in our project (Reactjs/Hapijs/MySQL). I checked the documentation and they have many examples and that is great, however, I can't find any related to how exactly do I use my existing user database.
In my application I have users and those users can have one or more projects. With the authorization that we currently use, a user logs in, I check what projects does he own and send it to the React application.
I am missing a document that explains me how to use Auth0 and still be able to check in my database what projects user owns.
My idea on how that should work (I might be wrong):
User sends username and password to our server
Our server makes request to Auth0 (with provided credentials)
Auth0 replies back to our server with some token
We look in users table in our database and try to verify the existence of that user
If it is a match then we simply look (as we already do) for user projects.
Is this how it is supposed to work?
There are a few options available for scenarios where you want to integrate Auth0 with applications that already have existing user databases. You can either:
continue to use your existing store
progressively migrate your users from your custom store to the Auth0 store
You don't mention it explicitly, but judging from your expected flow it seems you would be wanting to implement the first option. There is specific documentation that you can follow that explain how you can setup your custom database connection, see Authenticate Users with Username and Password using a Custom Database. It mentions MySQL, but others database servers are supported and there are many templates that will allow you to quickly setup things.
When you complete this the final flow will be the following:
Using either Auth0 authentication libraries (Lock) or your custom UI you'll ask the user for their credentials
Either Lock or your custom UI submits the credentials to Auth0 authentication API
Auth0 authentication API validates the credentials by calling scripts that execute against your custom database (these scripts were provided by you when you configured the database connection)
If the credentials are valid the Authentication API will return a token to the calling application that will have user information and proves the users is who he say he is.
The scripts you need to provide are the following, but only one is mandatory:
Login script (executed each time a user attempts to login) (mandatory)
Create user script
Verify email script
Change password script
Delete user script
The optional scripts are only required when you want to provide the associated functionality through Auth0 libraries, if only need the login to work then you can skip them. The login script, in the case of a valid user, is also where you return the profile information of the user, for example, you could in theory include their owned projects in the user profile.
I have been building a mobile-web-app in HTML5/JQuery and as part of this app I need to require users to log in to Moodle on the app.
Unfortunately I have no idea how to do this.
I'm not sure if I can create a log in form on my App that will check User details with moodle, or if I need to redirect to moodle and get a response from there.
There are a lot of vague, confusing questions about this, so I'm going to be as clear as I can about what the app should do.
user opens App A
App A asks the user to use their moodle details to log in
Moodle tells App if log in was successful
App A either displays an error, or allows user access to the app.
If somebody could help me out here I would really appreciate it.
You can use moodle auth plugins for enabling SSO.
If you are hosting moodle on the same domain, cookies can be shared between App A and moodle and you can use the shared cookies while validating in moodle auth plugin.
And if domains are different, you would need to pass cookie (e.g. sess_uuid) in query parameter and grep it in your auth plugin and use it to validate against App A database (may be using REST call) and if cookies is valid, you can lookup for the user (identified by details provided in cookie validation call) in moodle. If user exists in moodle, you just need to set the global variable $user in the plugin and if user is not present in moodle, depending on you requirement, you can either create new user or do not set user in the plugin which would eventually cause login error.
I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?
Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.
I'm looking for a short tutorial about creating a login page for a website using cookies.
Each user has a username and a password.
Should I save both the username and the password in the cookies ? or just the username may be enough ?
Can a malicious user steal somehow these cookies and pass the authorization ?
It's not a good idea to store the password in the cookie. If you store just a username, your system is basically completely unsecure. Remember that the client has complete control over the contents of cookies it sends to the server. It can send any username it wants. You should create an authorization token for the specific session (probably with an expiration time associated with it) and store that in the cookie. To prevent tampering with the cookie, you should sign (and encrypt) it on the server and validate the signature.
That said, doing that correctly is not an easy task. Don't reinvent the wheel. Use the authentication mechanisms provided by your platform.
There are many ways to do authentication in PHP. Just google one
http://www.developertutorials.com/scripts/script-details/307067.php
You will want to store you user's passwords in a database, and keep obfuscate them in some way. PHP has a built-in function called md5().
Here's a guide on php.net to help you through.
http://php.net/manual/en/features.http-auth.php
I'f you're having trouble grasping these concepts, then I'd recommend working through a php framework. My framework of choice is cakePHP, which makes stuff like authentication a breeze (another top framework is Code Igniter).