One thought is to not allow form submission if there is not a value in the password box. Generally if they accidentally entered the password in the username, then there likely isn't going to be anything in the password dialog.
It is worth noting that this does not have to be simply done client side, but could also be done on a server as long as the ...
I highly doubt it.
You didn't press enter but Google will sometimes send the information to quickly present your results. This is forced over HTTPS. Your information was likely encrypted and not exposed.
According to most sources Google processes on average 3.5 billion searches per day. There is no additional information to prove your query is a password. ...
There are clearly 2 different lines of defense here.
First, highly sensitive data (secrets, typically passwords) should never be logged to avoid compromise through logs.
But the more an attacker knows about a system, the higher the risk to build/use a targetted attack. For example software versions are not highly sensitive and can reasonably feed a log, ...
To, answer your question, Yes, you can and SHOULD log password-changes, and there's nothing fundamentally wrong with doing so, as long as you don't e.g. record the password itself"
What to log?
When designing logging for Security purposes you want to address these questions:
When did the event happen?
The date and time the event occurred (Use the common ...
Yes, failed login attempts should be logged:
You want to know when people are trying to get in
You want to understand why your accounts are getting locked out
It's also very important - older Windows logging process never emphasized this enough - to log successful login attempts as well. Because if you have a string of failed login attempts, you really ...
The accepted solution to this is to not store the logs locally, but on a log server. Once the logs are there, you can restrict or limit access as you see fit.
In some log server/aggregator solutions, you can limit a user from seeing entries that contain references to certain data (like their user accounts or machine IPs). This means that you can enable ...
I recommend that you change your password. The fact is, that your password has been sent to their servers, even if you didn't press enter.
You can test that on your own, open your browser, Ctrl + Shift + I, select network, start typing and monitor traffic.
Here is an example, writing the keyword "test", and not pressing enter.
Pay attention to the letter ...
There is no "correct" answer to your question, unfortunately. Data retention policies are specific to the needs of an organization, and are often implemented out of necessity to comply with various legal requirements , which vary depending on the nature of the data being stored, as well as the jurisdiction that the data falls under.
Retaining log data can ...
What are the strengths of each team member that I will work with regularly? (i.e. programming, linux, networking, regulations, etc.)
Where is our documentation? You hopefully have a wiki, a knowledge base, or set of documents somewhere that explain your processes and policies. If you don't, be a hero and get started on one.
What are the current projects the ...
Assuming your backend application and SIEM needs to view failed login attempts to various applications (and thus show the "User P@$$w0rd is not valid" error message) then it is not going to be trivial to stop this.
However, ensuring that all applications that send sensitive data including usernames and passwords implement HTTPS (encrypted HTTP using SSL) is ...
The goal of GDPR is about protecting personally identifiable information (PII) as much as possible. The interaction of a specific user with your application are pretty sure such PII.
If you really need to log this information you should inform your user about this process, i.e. the purpose of the data collection, how long the information gets stored and ...
The short answer is that it is very, very likely that your concatenated username and password exist on an unencrypted log somewhere that a larger group of people would conceivably have access to than the restricted logs.
You are not paranoid to change your password and should change it when this happens.
Access to raw log data should be restricted to authorized users.
The simple reason for that is that even when under normal operating conditions your applications may should not log any data too sensitive to expose (and opinions/regulations on what that is exactly may differ) there almost certainly will come a time when your logs do contain sensitive data:
Logging data is not the issue under GDPR. The part that matters is what happens to the log, who can see it, how long it is stored, what the log is used for, and if you can satisfy the rights of the data subject once you process and store the data.
If you need to log the email in order to provide your service, then there is no problem to log it. But if you ...
It has been sent (encrypted) to Google. Change your password
It has probably been logged somewhere, along with many search terms and other junk people have typed there. While it's unlikely it will be used for anything you care or that endangers your account, why bear the risk? Simply changing it will solve it.
PS: I recommend using a browser search bar, ...
I don’t think that “legal” is the right term to use.
It’s not wise, a lot of times “right” password is only one letter different from the “wrong” password (typo/capital letters/…).
So if somebody evil will get this log he may easily guess the correct password.
Other problem is that people re-use passwords, so they use same password for your site/gmail/...
The key word is properly.
Properly logging HTTP requests when there is a need for it is not bad practice. I am a pen tester and I log all the HTTP requests that I make as part of a test; doing so is expected. I also work on a server system that integrates with a number of complex legacy systems. Logging full HTTP requests on error is a necessary feature. It ...
So the problem is that you don't want analysts to see the passwords in the sensitive log files?
A better solution is to preprocess the logs before the analysts see them and redact information in the logs.
You can do this line-...
I can only identify three problems with what you're discussing.
Users aren't inputting information correctly.
Analysts can discern passwords from logs.
Passwords are being sent in clear-text and are susceptible to man-in-the-middle eavesdropping.
In my opinion, this is fairly simple to fix.
Accept user error, grudgingly.
Don't log invalid usernames, ...
HTTP 200s can be awesome for an attacker when he is requesting URIs that should be protected by authorization (http://cwe.mitre.org/data/definitions/862.html).
Attackers pay notice to HTTP 500s – they often lead to offensive success. Observing lots of HTTP 500s can be interesting. If the app likes to redirect (HTTP 302) upon errors, then lots of HTTP 302s ...
It has more points of view:
1) By not hiding logs, you expose your infrastructure.
2) EU has a GDPR. Exposing IP's, names, e-mails or anything personal is prohibited. (and at least immoral and bad behaviour) gdpr-info.eu/art-32-gdpr
If you need to show the logged data to third party or an easy access use dedicated tool. In my office it's graylog for ...
Generally, the most conservative answer comes in the form of something easily understood, and approachable by the general populous.
Ignoring the hyperbole of that kind of response, there are two things you must really take into account.
What logs should I retain
How long should I retain said logs
The answer to 2 is simple and well defined ...
Yes, log file injection can be useful in the exploitation process. For example, here is an exploit that uses a PHP Local File Include vulnerability to execute PHP code within Apache's access_log file. This exploit pattern is common in the LAMP world.
Most systems lack protection against this attack pattern. Usually log files are protected by the ...
Storing logs is cheap, more often they're ASCII/UNICODE and easily compressed for long-term archival.
Keeping your logs is better than purging for the reasons you can't anticipate.
But a minimum, a ten-year retention policy is an industry best practice for US-based businesses since the federal statute of limitations and in most states is a ...
This is a major problem when proving auditability, as IT folks tend to have access to servers and theoretically could alter logs.
A common solution is to write logs to somewhere inaccessible to IT/Sysadmins etc in addition to the core syslog servers, for example offsite or to a WORM drive (Write Once - Read Many)
This allows you to use your normal syslog ...
But if this happens my password would be stored in some unencrypted
log somewhere, right along with my username.
Is this a reasonable concern?
Am I being too paranoid?
If your worry is about the password being stored, then absolutely you're not. Your password will get stored in the clear to a near certainty. Being aware of ...
Bash history won't help you against a semi-competent attacker in the usual case.
There's an alternative: The auditing subsystem. Install auditd and configure it, so it logs for example program executions and other things you configure. In basically logs the system calls that are made according to filters you have created.
Now, if you really want to depend ...
If the stats that you are collecting are just as simple as "Have i seen this IP before?" then a Bloom Filter is ideal. Bloom Filter lookups and inserts are both O(1). But most importantly you cannot reverse a bloom filter, not even using brute force due to an unavoidable false-positive rate. You could have an array of bloom filters to put the ip address into ...
A solution I have seen a few banks implement, at least in web apps, is to have a two page login.
On the first page accept only the username
On the next page in the process request the password and only echo the username back so it is not an editable field
Therefore the only input on the second page should be the password. Since the user knows they must ...