i am working on a cakephp 2.x. i am using auth component .. i want to ask if that possible in auth component to track the user fail login attempts and also i have searched on google and i found this component
http://bakery.cakephp.org/articles/aep_/2006/11/04/brute-force-protection
should i use this in my cakephp 2.3 .is that component is compatible for 2.3 ?i want to prevent my app from brute force attact. so is this component is perfect for me ? or if there is any else good component there too or a better approach to handle the brute force?
No, that is a bad approach IMO.
First use blowfish or some sort of hashing with "slow encryption". That is the most important base factor.
Then don't use Session, IP or other easily spoofable data to secure your login, but the actual user record the user wants to login as. This way the attacker cannot influence the amount of login attempts by changing his IP or other identification features. It also protects better against bot net attacks (using multiple computers at once).
So if he tries to login as "carl", count the logins made to this specific account and black hole if too many requests are made within a specific time (temporary disable login for this account). He can still run through all users this way, of course, but he will never ever be able to actually brute force the user.
You should "enable login" for this user again, though, after a specific period of time.
Related
I would like to add functionalities depending on whether or not the user logged in is the administrator but I don't really know which condition (for conditional rendering with delete buttons etc) I should use to check if the user is the admin or not. Is it safe to do it based on the id of the user ? In the first place, I thought about testing the user in every component I want him to have functionalities, with a state called "user" using recoiljs to get access to the user in the whole app but I'm afraid people could change the state with the react tool extension and then pretend they are the admin and so delete articles and stuff... What's the best way to test if a user is the admin or not using firebase authentification in a react project ?
It's never safe for client code to assume admin responsibilities without absolute enforcement from your backend. It's unsafe because client code can be compromised and might not work the way you expect. And it's running on a device that the user controls fully.
Client code can check some indicator to see if the user is admin (in whatever way you find suitable), but the final check needs to happen on your backend, either through security rules (if you're using Firebase products like Realtime Database, Firestore, or Cloud Storage), or in code running on a secure backend, including products like Cloud Functions.
I am new to Salesforce, but am an experienced developer. I am provided a link to a Salesforce report, which mostly has the right filters (query). I would like to use an REST API to pull that information as CSV or JSON so that I can do further processing on it.
Here are my questions:
Do I need special permissions to make API calls? What are they?
Do I need to create an "app" with client-key & secret? Does my admin need to grant me permission for this too?
There are a lot of REST APIs from Salesforce, which one do I need to get the info from the report? Analytics?
How do I authenticate in code?
You'd have to work with the System Administrator on the security pieces. Anybody who knows how the company works, can all users see everything, is there Single Sign-On in place, how likely is the report to change...
You will need an user account to pull the data. You need to decide if it'll be some "system account" (you know username and password and have them stored in your app) or can it run for any user in this org. It might not matter much but reports are "fun". If there will be data visibility issues 6 months from now, you'll be asked to make sure the report shows only French data to French users etc... you can make it in report filters or have multiple reports - or you can just use current users access and then it's the sysadmin that has to set the sharing rules right. (would you ever think about packaging what you did and reusing in another SF instance? Making a mobile app out of it? Things like that, they may sound stupid now but will help you decide on best path)
The user (whether it'll be system account or human) needs Profile permissions like "API Enabled" + whatever else you'd need normally ("Run Reports" etc). If you're leaning towards doing it with system user - you might want to look at Password Policies and maybe set password to Never Expires. Now this is bit dangerous so there would be other things you might want to read up about: "API only user" (can't login to website), maybe even locking down the account so it can login only from certain IP ranges or at certain times when the job's supposed to be scheduled...
Connected App and OAUth2 stuff - it's a good idea to create one, yes. Technically you don't have to, you could use SOAP API to call login, get session id... But it's bit weak, OAuth2 would give you more control over security. If you have sandboxes - there's little-known trick. You can make connected app in production (or even totally unrelated Developer Edition) and use client id & secret from it to login to sandboxes. If you create app in sandbox and you refresh it - keys stop working.
(back to security piece - in connected app you can let any user allow/deny access or sysadmin would allow only say these 3 users to connect, "pre-authorize". Could be handy)
Login - there are few REST API ways to login. Depends on your decision. if you have 1 dedicated user you'll probably go with "web server flow". I've added example https://stackoverflow.com/a/56034159/313628 if you don't have a ready SF connection library in your programming language.
If you'll let users login with their own credentials there will be typical OAuth "dance" of going to the target page (Google login, LinkedIn, Twitter...) and back to your app on success. This even works if client has Single Sign-On enabled. Or you could let people type in their username and pass into your app but that's not a great solution.
Pull the actual report already
Once you have session id. Official way would be to use Reporting API, for example https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_get_reportdata.htm
A quick & dirty and officially not supported thing is to mimic what happens when user clicks the report export in UI. Craft a GET request with right cookie and you're golden. See https://stackoverflow.com/a/57745683/313628. No idea if this will work if you went with dedicated account and "API access only" permission.
I am trying to learn BDD cucumber and i am trying to write a feature file for login scenario with valid and invalid usernames.
For valid user will be logged and will logout however for invalid username, the user will be asked to go to login page again and asked to write correct credentials.
I would like to ask, can we have both positive and negative scenarios in "Scenario Outline"?
Could you please help me in writing perfect feature file for this simple scenario?
Take a look at my feature file code ( PS, I am a beginner :))
Feature: Login Action
Description: This feature will test a LogIn and LogOut functionality
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
When User navigate to Login Page
Then User enters "<username>" and "<password>"
And Keeping case as Valid
Then User should get logged in
And Message displayed Login Successfully
Then User enters "<username>" and "<password>"
And Keeping case as InValid
Then user will be asked to go back to login page
And Provide correct credentials
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
|abc1#gmail.com|dfsd2|InValid|
Scenario: Successful logout from application
When user logs out from application
Then Message displayed Logout successfully
And Browser quit by driver
'Perfect' - Ain't no such thing...
The ScenarioOutline you have written is very confusing and possibly a wrong interpretation of how scenariooutline works. Basically you are logging in twice with each row of the examples table ie. same username and password (line 3 and 7 in the SO). In a scenariooutline all the steps will be repeated with each row of data that u provide in examples. Refer to multiple tutorials available.
Why mix up valid and invalid logins? Keep them in separate scenarios. Easy to follow.
Move the logout to a separate feature file.
Then you can move the first 3 steps of the login scenario into a background. Reduces repetition.
You are going to have a problem with checking login functionality for the valid case for multiple data. Once a valid user logs in then most web applications store the login credentials in a cookie etc etc. So when a new request is made for login page it might just skip the login page and land up in maybe lets say home page. Then you will get the NoSuchElementException when the selenium code looks for the userid input box. So for valid cases you need to have a logout too.
#Login
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
....
....
#Valid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
#InValid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
To run the Valid Login cases use the tags option in runner as {"#Login","#Valid"} or if on cucumber 2 #Login and #Valid. For Invalid one replace with #InValid.
As pointed out here in an excellent answer - each scenario is essentially one test case and must therefore be clearly separated.
Nevertheless, it's critical to understand that Given/When/Then (in their most basic essence) are equivalent to the traditional three stages of a system test: Arrange/Act/Assert, therefore:
Given: Arrange the system in a known state
When: Command the system (what you want to test)
Then: Assert that the outcome was what you expected.
That's it! (of course there's a lot more to BDD than that - but these are the basics of an executable specification)
Given User is on Home Page is not arranging the system in a known state, but Given I am registered is. Though it might not be enough to state just this, because as soon as you go through the whys and whats of the scenario you'll quickly realize that you're missing something more concrete as an example.
To paraphrase the previous answer:
Given I am registered -> set up the user (but does it matter who?) as being registered in the system (database entry?), registered for what? does it matter to the outcome?
When I sign in -> Give the system the command to sign-in (who?) - this might be done via a web form or via an API (or over the phone?). Does it matter what time you sign in, can you sign in immediately?
Then I should be signed in -> Check response from web app, database, session? cookie?
Saying that, logging in scenarios are probably not worth using BDD to tackle since they are as well defined as CRUD - there's almost no need for analysis.
Scenario: Good sign in
Given I am registered
When I sign in
Then I should be signed in
Scenario: Not registered sign in
Given I am not registered
When I sign
Then I should not be signed in
And ...
Scenario: Registered with wrong password
Given I am registered
When I sign in with a bad password
Then I should not be signed in
And ...
Tips:
Keep things simple
Don't use outlines
Keep details of HOW you do things out of scenarios
Have one scenario for each path
10 simple scenarios are better than one complex one.
You can see details of how to write scenarios like this (in Ruby) at https://github.com/diabolo/cuke_up/tree/master/features.
Caveats:
this is just one persons opinion
you need to be able to write code to work this way (as you push all the details of how things are done out of cucumber and into helper code).
registration is a pre-requisite to sign in
I'm building an admin page for an application and have a state value 'authenticated' that flips from 'false' to 'true' after a successful login (which is authenticated on the server) which then shows the actual admin panel.
Are component state values safe from tampering by the client? Basically, if the client can modify my 'authenticated' state value to 'true', they can skip the login and go straight to the admin panel (which I obviously don't want).
I read that React Dev Tools allows the client to modify values yet everyone says "validate on the server" but I am validating on the server and updating my state accordingly, if the user is approved. If it is not wise to have a state value manage this, what is the right way to conditionally show the admin page after a successful, server-side authenticated login?
I think this is an important question since tampering with state values in a React app can have huge negative consequences on data integrity within an app/database.
TL;DR: Either require an authentication token with every request or require authentication through a session.
Never trust users always. One potentially big issue is if you "hide" admin actions behind the admins page without requiring authentication.
For example, assume the backend server uses a REST API to accept commands. In the admin panel you get links to administrative actions like a button 'Delete Everything' that sends a DELETE request to server.net:8080/api/admin/everything without requiring any authentication. If you're a user, you can find that in the code potentially and then send a DELETE request to that address from anywhere without any repercussions.
We'd never give administrative privileges to anyone who would want to delete everything... Because we'll never untrust someone. Right?
Worse, someone might find the server and fuzz some inputs to it, and oops! They manage to delete everything (or even worse, GET everything stored in the database). This wouldn't be hard to do, especially if the server you use to authenticate is the same server you use to issue commands. History has proven "security through obscurity" to be a very bad paradigm. Every action should be authenticated, even if it seems like the actions will be hard to find.
Generally, providing a JSON web token or some other form of authentication token and having the user send that with every request is a good start at least, especially if it has an expiration date. The token would be provided through a separate request with valid credentials.
Sending a token with every single request obviously isn't ideal. There are a couple of other things to try. For servers using PHP, you can probably trust sessions (though very many people who know more than me would probably disagree). In more modern cases, you could try to use Web Sockets, requiring the token after connection. Then only after authentication with the token do you allow the user to make administrative requests.
That way, even if a user knows the exact command they can send to perform any action, the server won't let them without a current session or token. Unfortunately, unless you're already using Web Sockets or depending on a session, it will likely require a lot of changes. I'd consider this to be critical though.
It is always possible to tamper values in the front-end, there is no way you can rely solely on the front end to ensure security.
Your best approach is to implement some form of authentication and authorization on your backend. In this way, even is some users pretend to be admin, they will be blocked when you do the next request to the server.
Perhaps if you can send more information regarding your problem, we can think of a more specific solution.
I have created a web page with RoR and i am using auth system that i wrote. Now i would like to create an admin panel, where i can see the user info etc..
I am not sure but what i though is to add a column name to auth system like admin? giving a default name false. Then if the admin? is true admin panel opens instead of the web page login.
I wonder if i can use the same auth system so in order to login to page it logs in to admin panel.
But in the controller it will check if admin? is true for every user, i am not sure about the burden in terms of the system requirments as it will check every user.
And i know there are other gems for admin panel but its fine i can design it. I am just not sure which way is the efficient way.
The burden on the system will be negligible. It depends a little bit upon how your auth system is configured, but I am assuming that you give the user a token when he/she is properly logged in.
When the user first tries to sign in, you should check if they are an admin. At this point, if they are, then you can sign them in as an admin, also storing that information in the session. You should perform this check on the controller actions where they need to be an admin. It will not affect performance to any noticeable degree and is important for the security of your site.
Also, you may want to check out the CanCanCan gem, which is a fork of CanCan built by Ryan Bates, for an example of how this works. Unless you're building the application for educational purposes, I highly recommend the CanCanCan gem.
Hope this helps!
In addition to that, you may try Rails_Admin, which provides an easy-to-use interface for managing your data.
And I've considered to use this gem for my project, which is a huge database, so it seems to very helpful.