So first it would be good to consider what kind of database you'd like to use, and then secondly what kind of adapter you can use with it.

Regarding databases and log storage, the main factor is about storage - the storage model defines what it will be like, and these models you can categorize like this:

Unstructured text files (smallest size, fastest ingest)
Structured data (medium size, medium fast ingest)
Structured data with indexes (big size, slow ingest)
Structured data with indexes and full text search (very big size, slowest ingest)

So, based on that you can do the following:

Use BigData storage with Hadoop like processing. This is over-kill for the task.
SQL tables without indexes, MongoDB without indexes
SQL tables with indexes, MongoDB with indexes
SQL tables with index and with full text search, MongoDB with indexes and full text search, Elastic Search

SQL and MongoDB are both most user friendly due to availability of various GUIs and SDKs which are easy to use (as of 2016). There are also other engines like Cassandra, Splunk.

So now, from my experience, the best usability / scalability / easy to use is to use MongoDB table with primary index and eventually some optional when it's needed. This is because MongoDB with it's newest WiredTiger engine it compressed data so typical log entry from Apache takes approx 90 bytes of space on disk (with indexes). Compared to uncompressed SQL it is very good result, and secondly it allows you to define called collections (tables), which can be limited to e.g. 4GB which gives you 50M log entries. So then, after hitting 50M entries, it will be overwriting old ones.
Another advantage of MongoDB is that you can ingest JSON Document without need to define table structure, it just takes any JSON document.

Comparing e.g. other SQL engines, there's problem with removing old entries and sometimes the indexes has to be rebuilt (there's no way without at least primary index). This makes it lot more complex in a way that this data needs to be inserted into new table every day, so implementation of it is a lot harder.

Regarding Search Engines, the search functionality is really not needed. This is very good marketing but very little benefit for a lot of hassle when it comes to log parsing. In fact, searching is for manual operation and once you perform search of two it happens to be not needed any more, yet all data storage and ingest is designed for searching.

What is the best usage of such data is to e.g. run Nagios check (as good example), and storage the values in RRD table and generate graph with pnp4nagios. So each check run every 5 minutes checks last 5 minutes worth of logs and based on that take data point and ingest into Nagios.

For Elastic Search for example, there's front-end for viewing data but it's not reporting tool, for reporting on e.g. httpd logs you can use Sawmill instead.

Finally, you need adapter which can do one of the following:
   - Accept SNMP traps
   - Accept Syslog messages
   - Accept JSON formatted documents over HTTP/HTTPS (usually it is using keep alives)

There are few options to do it like using Syslog with Database plugin, so basically logs are passed to Syslog and Syslog is loading it to database. But then, you need to also construct SNMP trap or any kind of sink separately. There are few other commercial sinks for these tasks optimized for Splunk, there's something with Greylog2 as well.

However what seems to be easy to implement is Spring XD, so basically you can establish Syslog source and JDBC (SQL) / JSON/ MongoDB output. It is very easy to do and once running it should be OK. You do not need any extra code to have it up and running.
You can then use Syslog as source from servers and from router as well. You need to find out which Syslog format is good, and you can start many Syslog listeners with many Syslog formats. So this should work fine for router.

Now, as SQL for example would seem to be easy option, when there's more entries like HTTP etc, MongoDB performs better, and also if Syslog seems easy as well, it may not be good for large number of requests. Therefore for medium-size installations (like if you are not Facebook or any big website), MongoDB is good because it's easy with GUI, API, capped collections and small storage / RAM requirements.

Then it comes how do you ingest  HTTPD logfiles into MongoDB. For the integration sake it's good to use Adapter as well and some kind of universal one, for example HTTPS JSON -> MongoDB or SQL, and then make server on which HTTPD is running to tail the logs and ingest send it to the Adaptor as JSON documents so there's field name and field value. So when you change log format then it's no pain to change the database schema or even queries.

So this can be achieved with daemon which tails the httpd log and sends HTTPS / JSON documents to Adaptor. For example many people are comfortable with Perl but most recently with Python. This is not really difficult think to do. The Apache log format is stored in it's config, so from this you can work-out the log format and it's columns. Sometimes there's log field description in the header. The daemon is good option because it doesn;'t interfere with anything else, but making Apache writing to Syslog also works, however you need structured documents or SQL table data and not single line.

The above methods are highly reliable and scalable and you are not in any vendor lock-in. For example, Nagios is good monitoring tool and since it doesn't realy on any database itself it's very hard to break it while it's very easy to install / revert any changes as you can have them in Git. And it can do both rendering and alerting like email notifications. Plus, you have various Front-ends like Thruk which is nicely packaged for many distributions.

In overall, the above gives you the lowest cost, smallest infrastructure requirements and good flexibility. Going with any search engine is huge over-kill and it will not make it any easier even if the start looks easy. Being familiar with database APIs other than SQL is apparently needed, some bit of scripting and the Nagios. These are standards and this can scale to a lot of more devices. It's easy to make Nagios monitoring bandwidth and so on. It's not by default, Nagios plugins do miss big time plenty of things but it's easy to make it happen with a bit of SNMP experience.

Search engines are not good for being used by Nagios. They are useful for used by people. So if you want alerting it's better to use something else than Search Engines. It is just huge over-kill for the task and you might find yourself working on something which in the end has little benefit even if you have believed in it.

What you really need is:

Proper reporting like Sawmill, and Search Engines with their front-ends are nowhere close to it today
Proper alerting with Nagios (it's not as good or not at all with other alternatives)
Stable, mature database with scale-out options which works
RRD based drawings, the round-robin in MongoDB and RRD in Nagios is what it is all about
Proper front-end to Nagios like Thruk
Good database client like Mongo3T, SQLYog for MySQL etc
Good scripting language with good environment (definitely not tons of Regex).


Can a spoofer intercept my email, insert text and send it on?

Email is not secure. It is very easy to send a completely fake email. Moreover, someone who can eavesdrop on an email while in transit can most often alter the transmission at will, in particular blocking the email, modifying it, and/or adding extra emails in the stream.

A classic method for email interception, at the network level, is DNS poisoning. Through some fake DNS responses, the attacker induces then sending email server to talk to him instead of the genuine destination server. The attacker can thus not only see all the data, but it is entirely up to him to decide what he will forward to the actual destination server.

Another vulnerable place is the incoming mailbox for the recipient. That mailbox must exist as some file on some server. Any server admin, or any of his interns, or any attacker who got access to that server (e.g. the server also hosts a vulnerable Web application, or whatever), can at will read and write emails in mailboxes.

Technically, you could have sent the fake email yourself, in order to later claim that there was abuse, fraud and deceit. Emails, by themselves, cannot decently serve as proof in either way.

(Emails occasionally do serve as proof, but only in contexts where involved parties don't feel that they could make a strong defending case. Emails are invoked in courts as data elements which were seized by police services on actual machines. In your case, you have full control on the machines on your side, and your adversary has full control on the machines on his side; and legal seizure is unlikely to occur in a cross-continents dispute.)


You should indeed consider local privacy regulations. The EU, in particular, has stringent privacy regulations.

Here are some good websites where to get additional information:

Privacy By Design (Canada)
EU protection of personal data (European Union)
OECD Privacy Regulation (World)
CNIL (France) - from ther


Exploit "Blind" buffer overflow in a lab

You should always be searching for an instruction (ex. JMP ESP) in an application lib first when writing exploits, as this will increase reliability across OSs/SPs.

What instruction did you use for your working exploit (more info on this will be very helpful)? If it was an OS library that is likely the issue, assuming the target is a different OS or SP level.

On x86 machines, I would use Immunity and mona.py to find appropriate instructions for your exploit. You can find a port of mona to x64dbg as well.

Given this is a CTF exercise, it should be possible with the information available to you, making me think that the application's libraries should be the answer. Another idea is -- what enumeration activities have you tried on the target machine? Can you pull back any information leaking more info about it?


Is the password hash better when you concatenate the password and username?

What you are describing is a Salt. The primary purpose of having a salt is to protect against rainbow table attacks. Ideally though, the salt should be randomly generated, and not be derived from the username.


Can I move my private-key to a better token?

Once you have deployed a private key in a USB Dongle it is impossible to extract it. This is the main reason to use a USB Dongle, to ensure the key is always hardware protected.

The only option is to generate a new private key and request a new certificate


Why don't CAs sell certificates as files, instead of hardware or as a service?

It's rather simple:
If you want a certificate which is from a CA root that is in the Adobe’s Approved Trust List (AATL), the CA and you have to comply to the technical requirements.

EE4 c. clearly requires

  All end-entity key pairs must be stored in a secure cryptographic hardware device ...

If you don't need a certificate which complies with that, you can surely buy one or create one yourself. It will not be on the AATL of course.


As long as you are very careful about the client-side hashing function, it would seem like there is no reason you couldn't. But wait!
You do need to remember that not all passwords are for web-based applications with a single client written and distributed by the author.
Instead, it could be an arbitrary API. Adding the requirement that the password must be hashed using a specific function adds complexity to the implementation.
In yet other cases, the password could be set server-side (think SQL servers where the "set password" command is literally a SQL statement). Should the initial hashing function be poorly chosen (think md5 for postgres), you're now stuck with it until all clients support the new hashing function and all users have  changed their passwords.
It might at first seem like a practical reason and not a security reason. But this becomes a security issue 10 years later when your protocol is still being used and most clients still only support a terribly insecure hashing function (and yes, this is the case for postgres).


sqlmap have in test patterns Boolean-based with Time-dependent SQL injection but you must specify where you want to test SQL injections patterns.
So in my case I used option --user-agent="*" which should be empty user agent and * is specifying where this patterns will be tested (because in my case it do not require have something in it).
One more tip - when someone is using sqlmap over tor and want to test Time-dependent SQL injection, you must specify --time-sec= to atleast 4-5 seconds due the tor network speed.


How to store data that the computer can read but not the user?

There is two ways this can be "more-or-less" achieved (as the other answers pointed out, there is no 100% safe way, as there is no 100% security in general):

Software obfuscation: it relies on the fact that the execution flow of a program is voluntary and artificially made so cumbersome that it becomes very complex to grasp its logic and understand what is concretely done among (hundreds of) thousands of no-op and misleading operations.

You can find such systems used by DRM enforcement software: the program itself will be able to read the DRM-protected files, but you will not, neither will do any non-DRM compliant software. This is done with the intent to allow you to open a file in a restricted manner (for instance only during a limited period) with no ability to copy it or do any unauthorized actions (printing it for instance).
Specialized hardware storage: some chips allow to store some information with no possibility to read it back, the chip itself will have internally a full access to this information and will therefore be able to provide some services around this information.

This is typically used to store private keys in HSM-like devices: a cryptographic key is stored in a chip, and programs running on the computer can ask the chip for instance to use the key to encrypt some data, but there is no way to read the key itself from the chip. This is used to ensure that even if some malicious person would be able to access the whole computer's content, he will not have access to the protected keys.


Many printers, especially those used in businesses, support IPP over HTTPS. If you have access to the printer's control panel, you can enable HTTPS and install a certificate that you trust. On your computer, set up a printer manually and specify https://printer-domain or printer-domain:443 as the printer's address, depending on what operating system you are using.

You can usually find documentation for your specific printer model about how to enable HTTPS.


Will a printer refuse HTTP connections from a non local address?

The answer is “no, your printer will not refuse connection attempts from an external system.” That’s not its job. It will happily accept connection requests from any system that manages to find its way through the Ethernet cable.

It’s the job of your network to prevent attackers from passing through your router and reaching your printer in the first place. Tools such as firewalls block external attacks inside your router before they can get inside your network. And it’s your responsibility, as owner/administrator of your router, to make sure that it’s properly configured to keep your network secure.


What is the point of sending an email informing a possible break in to the same account?

These emails are sent out whenever someone logs into your Gmail account, which is useful for when you are viewing the Gmail at the same time, or have a push notification service(like on your cell phone for notifications, which most people do). This service is asynchronous and ALL logged in users will see the email, even if one user sends it to trash(it would require a refresh on all users to see the message has been deleted).

So a common workflow for this is you're checking your emails when you are notified(instantly in the web and instantly by notification) that someone has logged into your account on a new device(or attempted too). If this happens you now INSTANTLY know in a way the hacker can't prevent. This gives you a small windows of opportunity yourself to stop the hacker while your Oath token is still good and you can lock the account(or if a bit too slow, start a recovery ticket). In asynchronous applications like gmail, yahoo mail, outlook, and many other providers where a login looks... fish-e... this can give the user time to fix the problem.

Now this may sound like "Well why doesn't the hacker just change the login details then?" Sometimes this happens, but if ready for it a user should be able to start the damage mitigation process themselves, and/or seek help to minimize the damage that does happen.


Metasploit: Is it possible to automatically kick off a script on a reverse-shell callback?

Yes. You can do this using the AutoRunScript function.

set AutoRunScript multi_console_command -rc /root/commands.rc

Where /root/commands.rc contains the commands you with to run.

For example

run post/windows/manage/migrate
run post/windows/manage/killfw
run post/windows/gather/checkvm

From this point it would be trivial to gain persistence.

For more information check these resources:

Autoscript

Metasploit automatic module execution on receival of shell?


Can't request ocsp status with chain of certificates

You have the following setup:

server.crt is issued by sub-ca.crt, sub-ca.crt is issued by root-ca.crt
OCSP response is signed by root-ocsp.crt which was issued by root-ca.crt

The process to validate a OCSP response is described in RFC 2560 section 4.2.2.2. (now obsoleted by RFC 6960) In short the OCSP response must be

either signed by the issuer of the certificate in question, i.e. signed by sub-ca.crt in your case.
or signed by a designated responder. This responder must have an extended key usage of OCSPSigning and must be issued by the issuer of the certificate in question. This means the responders certificate must be signed by sub-ca.crt.

You are trying to use the designated responder. Your responder has the correct extended key usage. But the responder is issued by root-ca.crt whereas the certificate in question is issued by sub-ca.crt. This conflicts with the requirement that the issuer of the responder certificate must be the issuer of the queried certificate and thus the validation fails.


Sounds like it is vulnerable, and you have hit the anti-XSS filter in modern browsers.

For testing I suggest you disable the filter.

When reporting these issues to clients, I take the line that you can't be sure whether a user will have such a browser, and report anyway. That has been ok so far, although I can see in the future I will need to distinguish between XSS that is exploitable through the filter (high risk) and other XSS (should still be fixed, but lower risk).


gpg2: How to get rid of "Please insert card with serial number", getting the same key from a different card / Yubikey

Solution

Delete the keygrips of the keys in question from ~/.gnupg/private-keys-v1.d.

You can list the keygrip IDs using gpg --list-secret-keys --with-keygrip.

If all your private keys are on external cards like the Yubikey, you can delete them all using:

rm -r ~/.gnupg/private-keys-v1.d

See here for more information about the private-keys-v1.d directory.

After the deletion of the keygrips, it seems beneficial to run

gpgconf --kill gpg-agent
gpg --card-status

to restart the gpg-agent and reload the card info.

Extra info: What happens when you don't restart/reload (for people who search for these error messages)

If you do only gpgconf --kill gpg-agent, the next decryption may show

gpg: decryption failed: No secret key

Reloading the card info fixes that.

If you do only gpg --card-edit, the next decryption may show

gpg: OpenPGP card not available: No such file or directory

Restarting the agent before that fixes that.

Personally I consider that a bad user experience, ideally GPG would automatically figure that out, but I don't know any technical details about it.


How to make OpenSSL errors more verbose for MQTT client?

Ok, here is the answer and it's not related to OpenSSL.

When you install Mosquitto from debian repositories, it gets you a v1.3.4-2 which is really old and not working as intended, at least in terms of SSL logs.

So just install the latest Mosquitto (v1.4.11 today) from the mosquitto.org repository, and you will get the full output :
https://mosquitto.org/2013/01/mosquitto-debian-repository/


Who defined the term "end-to-end encryption"?

The first reference that I found was from Paul Baran of Rand in 1964, in the manual On Distributed Communications. The link is to Chapter 9, which deals with security. Naturally, as this is from before the time of WhatsApp, Skype, Tor, etc., it does not deal with many of the threat models or use cases for E2E encryption that we see now.

This manual is further cited by Saltzer, Diffie-Hellman...


I'm just going to answer (very) generally and let you do the math.

IP address spoofing works just like any other form of spoofing. Spoofing means pretending to be someone who you aren't. In the context of information security, IP address spoofing (henceforth refereed to simply as "spoofing") is quite common in many attacks. For example to target systems which utilize IP address as a security control such as router access control lists, firewalls, trust relationships, etc. Additionally it's very typically used in denial of service attacks. IP spoofing in practice can vary from mundane to highly complex. In general there are really 3 common ways to do it.

You could simply just set your IP address to anything you want using ifconfig in Unix or netsh in Windows. Additionally many tools come with built in spoofing capabilities such as decoys in Nmap or you can use various packet crafting tools such as Scapy. This is great and all, but anyone with basic networking knowledge will tell you that isn't going be really very useful in many cases. Sure spoofing datagram protocols like UDP or ICMP is trivial, but what about TCP? First of all most ISPs ignore the source address so sure you can start shooting out packets with any IP you like and they'll probably get delivered, but if you actually want to have any sort meaningful interaction (ie. pretty much anything other than DoS) you're out of luck because the response will obviously be send to whomever you happen to be spoofing. This is the nature of session-oriented protocols like TCP. The three-way handshake is going to spoil all of your fun. For example: You send your spoofed packets (SYN [A, ISNa]) over then that machine (B) which will respond (ACK [A, ISNa+X] SYN [B, ISNb]) to whomever you happen to be spoofing (A), but the only response machine B will get back from machine A is a reset (RST). Now if you're on the same LAN as the system you're spoofing, this works a little differently as you could just intercept the messages. To get around this little problem with TCP one could try to predict ISNs. For this reason initial sequence numbers (ISNs) in TCP are supposed to be hard to guess.

I was actually going to go on, but I'm not really good at this and I'm tired so I'm just gonna close up.. with a few words. Maybe I will come back and finish this up at a later time. Sorry.

The easiest way that I know of to do spoofing is via source routing. Just use loose source routing, put yourself in the path and you're good to go. The only dependency is that at least one network path between you and your target supports source routing. I don't think this is really much of an issue at this time.

Now to defend against spoofing what do you need to do? Keep your TCP/IP stack patched. Don't extend trust relationships outside of firewalls unless it's over an encrypted tunnel. Don't use IP addresses for authentication (yes, people do actually do this.) Use anti-spoof filters on routers and firewalls, either direct anti-spoof or reverse path forwarding checks. Don't allow source routed packets through network gateways and especially not internet gateways. (Some networking guys seem to have a hard-on for source routing on the internal network, but it's always worth a shot) In IOS this is as easy as changing one setting. It's called "no ip source-route". Additionally anti-spoof filters can be set to generate logs and you could use some fancy machine learning techniques to detect non expected source addresses on a given network.

Sorry to cut it short, but I'm out. Cherrio.


Is spoofing the origin IP in a TCP header an effective "anonymity" strategy?

While this is a good idea in theory it can not work practically.
The TCP protocol uses a three-way-handshake, and so when you spoof the origin IP in a packet the packet with the SYN flag (First packet) will be sent but when the destination machine tries to establish a connection by sending an SYN-ACK packet back to that spoofed IP, the connection will fall since the spoofed machine will deny sending the first packet.

P.s: Some routers will not allow the sending of a packet not from the routers IP and drop it already by them and may even notify the ISP...


By definition a vulnerability is a weakness in software systems, be it web applications, the network daemon service running over a port or a thick application as a binary. A weakness could be taken advantage of using ex-filtration mechanisms - the primary reason to this could be two:

Extract data which is highly sensitive
Elevate furthermore privileges on top of what is already affected

An Exploit facilitates both of these factors. Hence, by definition an exploit or a exploit code should be an amplifier to an existing vulnerability on systems or set of different kind(s) of system(s).

If a vulnerability is detected during a lexical analysis which might be due to a source code security audit, a reproduction of the which attempts to either get you access to special data or otherwise grant elevated privileges fails, it doesn't mean there would be no vulnerability but what it does mean that there were no exploits readily available which can grant you any of these.

What could it grant?

May be chaining multiple vulnerabilities including the particular discovered vulnerability would
It might as well be that the vulnerability doesn't affect all systems but a specific instance depending on a platform it is hosted on or other dependencies?
The vulnerability is identified & advisories are released but previously it were a 0day which were sold off to the affected vendor which later never disclosed a potential full fledged step-by-step exploit code or any documentation of how a particular 'trigger' factor of the vulnerability would work.

To answer your question,

Vulnerabilities could be considered as a risk factor without a doubt.
Vulnerability does not always end up with exploitation or a working exploit availability.
Some Vulnerabilities are always exploitable depending the right chaining is done or otherwise the undisclosed working exploit code is released. This again depends on the vendor disclosing party.
Vulnerabilities are system weaknesses. It could lead to critical, high, moderate, low, or informational instances depending on how much sensitive data were leaked, how high elevated privileges were obtained.

Other factors might exist including but not limited to that of if the vulnerability could be chained to another potential vulnerability which happen to exist on the same system or set of system(s) affecting the CIA triad of security & hence compromising compliance factor.


Do any open-source firewalls support remote management?

All Linux and BSD-based firewalls are just a management UI over their respective IS kernel's firewall feature. If you want remote access and scripting functions, you can use standard remote management and scripting tools of the base OS, namely, SSH and shell scripts. The firewall products that support web administration can also be remotely accessed by configuring HTTPS with client certificates authentication (or many of the other authentication methods supported by HTTP/TLS).

The Linux and BSD firewalls don't brag about remote administrations and shell scripts because most people already expect them as being part of the capability of the underlying OS. Proprietary firewalls, on the other hand, do not necessarily support these things because people don't necessarily expect their custom OS to support shell scripting or SSH.


Unfamiliar with that particular unit, but throwing an SNMP trap on an interface up/down is not abnormal if the firewall itself is monitored with SNMP. It could also be LAN side hosts throwing the SNMP as a notification of timeout because of the tunnel outage.

Best bet is to get a sample and take a look. If it is a complex network, it probably isn't malicious. The other thing might be to run a ping monitor of your choice of the remote public interface, just to verify that the tunnel up/down is happening because of a layer 3 problem. Which it probably is, and examining the logs of the firewall will likely confirm that.

Just a few thoughts.


What responsibility do I have in continuing another developer's work?

You absolutely have a responsibility to maintain the confidentiality of financial records.

Depending on your country's laws and legal precedents (disclaimer: IANAL) it may be the case that you (as a company) could be prosecuted or sued for negligence in the case of a breach. I see that your profile says you're in the UK, so government organisations such as the ICO and FSA can get involved if a breach occurs and customers end up being defrauded because of it. They have a history of handing out hefty fines to companies who act irresponsibly with their customers' financial details. On top of this, individual customers can sue you separately, based on their individual losses.

Keep in mind that a breach that leaks a customer's personal information because of insufficient security measures automatically puts you in violation of the Data Protection Act 1988, which is something the ICO can prosecute you for.

In fact, your bank or card processor may require that you're PCI compliant in cases where you store financial credentials, so if that's the case then you may be in violation of the contract you have with them. In such a case they may revoke your services, fine you, or even sue you in court.

My advice is as follows:

Look through your system and identify what information needs to be protected, and what the best method is to protect it. For passwords, you should be using a key-derivation algorithm such as PBKDF2 or bcrypt - not a hash like SHA1. For financial information such as account numbers and sort codes, you should be using a HSM, or at least symmetric encryption with an in-memory key. Can you outsource your credential storage and/or payment processing to a 3rd party provider? Build up a list of suggestions and expected development times, and prioritise them by severity. Be realistic - saying everything is critical will make your boss switch off.
Go to your boss and explain that the current way your company is storing financial information is negligent and that your current security measures are insufficient. Explain why it's bad, what the appropriate legislation is around it (especially DPA 1998 and other ICO regulations) and the standards which most companies are expected to adhere to (PCI-DSS, ISO/IEC 27000, etc.). Make sure he fully recognizes the potential for severe financial (and potentially legal) penalties should you be breached.
Get him to talk to an information security company that specialises in PCI-DSS or similar financial regulations. Often they'll give a free (or cheap) consultation to go over any concerns he has, and give him some advice. From there he can decide what the risks are. It may well be worth having a thorough penetration test done on your web-app, since it's storing financial details. This is an expense, but it's much cheaper than being sued.
Take action based on the information you gain, and make sure you have the results vetted by a professional.

If, after all this, your boss still decides to ignore the serious security and privacy issues your web-app has, ask him to put in writing that you cannot and will not be held responsible for any legal issues related to data security breaches during your employment. If he refuses to do so, I highly recommend finding another job and reporting them to the ICO. It's not worth the potential legal problems.


Merchant sent email to me with all my Credit Card info

(Note: Not a PCI QSA, just know some PCI and PII stuff)

Violating the Payment Card Industry Data Security Standard is not a violation of the law.  The PCI DSS is an agreement between the payment card companies (VISA, etc) and the processors about how data will be secured.

The towing company is likely in breach of an agreement with their processor by doing this - and almost certainly would be more liable in case of leaked information.

If the email indicates the credit card processor, you could contact them.  You could also contact the towing company directly.  Lastly, as @Matthew suggests, you should let the bank know when you cancel.

A further possibility is to look at the Personally Identifiable Information statutes in your state (assuming you are in the US).  PII statutes vary widely depending on your location, but they widely consider the credit card number (known as the PAN) as counting as PII (along with the other personal information presumably in that email).  If your location has a privacy commissioner, you could raise it with that department.  Most PII statutes have requirements that companies treat PII with appropriate care and there are some significant penalties for not doing so in many jurisdictions.

For PCI, you can look at this info sheet on reporting violations


According to a paper published in Blackhat 2013, it isn't enough for you to implement Double-Submit Cookies in its own sub-domain (e.g. secure.host.com). You really must control all sub-domains:

  2.1.1 Naïve Double Submit

  Double submit cookie CSRF mitigations are common and implementations can vary a lot. The solution is
  tempting because it’s scalable and easy to implement. One of the most common variations is the naive:

if (cookievalue != postvalue)
 throw CSRFCheckError

  With naïve double submit, if an attacker can write a cookie they can obviously defeat the protection. And again, writing cookies is significantly easier then reading them.

  The fact that cookies can be written is difficult for many people to understand. After all, doesn’t the same
  origin policy specify that one domain cannot access cookies from another domain? However, there are two common scenarios where writing cookies across domains is possible:

  1) While it’s true that hellokitty.marketing.example.com cannot read cookies or access the DOM from secure.example.com because of the same origin policy, hellokitty.marketing.example.com can write cookies to the parent domain (example.com), and these cookies are then be consumed by secure.example.com (secure.example.com has no good way to distinguish which site set the cookie).

  Additionally, there are methods of forcing secure.example.com to always accept your cookie first. What this means is that XSS in hellokitty.marketing.example.com is able to overwrite cookies in secure.example.com.

Secondly, this approach is vulnerable to man-in-the-middle attacks:

  2) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies).

  Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plaintext HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as http://hellokitty.marketing.example.com doesn’t force https, then an attacker can overwrite cookies on any example.com subdomain.

In summary:

You must control all sub-domains.
You must set the Secure flag to ensure the cookies are only sent over HTTPS.
If you care about MiTM attacks, you must transition your entire website to HTTPS, set the HSTS header and ensure it includes all sub-domains. At this time, only 58% of browsers support HSTS (Internet Explorer being a notable exception). This is expected to change over the coming year.

See https://security.stackexchange.com/a/61041/5002 for a discussion of the token length and type of RNG needed to generate values.


Is it a good security practice to force employees hide their employer to avoid being targeted?

Hiding your employer would not appear to be of any use at all when you want to hide the employee's email address from the public. If you hide your employer info but spread your contact details far and wide, the employer info is not interesting.

The assumption being made is that once you know the company name and the employee name, then one can freely email the employee. Trying to address the threat of incoming emails by trying to hide the company name, so that the email address domain can't be guessed, so that emails cannot be addressed is trying to push on the wrong end of the lever of control. And you are trying to do it with a wildly difficult policy to enforce.

The trivially effective control is to break the direct tie between company name, employee name, and email address.

I know of companies that stand up a separate domain to send emails from. So example.com stands up example-email.com. This immediately wipes out a lot of automated emails. Other companies salt the email address with 2-4 numbers, so kelly.smith@example.com becomes kelly.smith.1234@example.com. Others use only the employeeID number: 12345678@example.com.

While each one of these can be overcome through analysis of other disclosed email addresses from the company, it is more effective and much, much easier to control and enforce through technical means than forcing people not to disclose where they work.

The company name is simply not the primary data to control in this threat scenario. It's the email addresses. You can control those.

Managing digital footprint is always a good consideration but you have an awareness problem and a trust problem with your employees that such a policy is not going to address.


You could do something like that (other solutions could be possible):

Step 1: The user fills the consent form.

Step 2: The server validates the consent form then generates a unique link to the questionnaire, not tied to the consent form. This link that can only be used to validate one questionnaire. The server flags (in its database) the session cookie as "consent form validated", but again, without linking to the consent form.

Step 3: The user fills the questionnaire.

Step 4: The server validates the questionnaire and the cookie, then invalidates the unique link and clears the session cookie.


Can you tell if a page does exist even if it throws a 404?

Throwing 404 error for every invalid request could be questionable, an attacker may start suspecting this behavior specially if he knows the service he is targeting.
Does this help protecting your service ? this really depends on the perseverance of the attacker.

Edit:
The attacker can detect the difference if you don't craft the 404 response header properly as the server would do
Here is a PoC for Java server case (Tomcat8):
This is a 'truthful' 404 status returned by the server itself for any not found resource :

Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1

This one is returned by the servlet :

Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1

You notice the parameter's value of "Content-length" in both cases, this one could attract the attacker's attention.


Assuming HTTPS here.

  Client connects to server and server responds with certificate

Yup.

  Client pulls the public key from the certificate and encrypts using this

Nope. Client uses this to handshake with server. Result of handshake is a shared secret. That shared secret, called the Master Secret, is then split up into separate server-to-client and client-to-server keys.

  Client sends message to server and server decrypts.

Yup. Client uses client-to-server key for that.

  What about when the server wants to send something back to the client machine that needs to be encrypted?

The server uses the server-to-client key to encrypt. And the client uses that same key to decrypt.


Short version: I think there is no danger doing short-cut comparison of salted hashes of passwords, if the salt is hidden to the attacker.

Long version:

Using timing attacks in this case will in no way tell an attacker more than what he would know if he had the actual stored hash and salt ... and brypt's security parameter (iteration count exponent) should be chosen such that even knowing the hash and salt would not give the attacker a significant enough advantage to derive the password (since he would have to brute-force the password from this).

On the other hand, if the attacker does know neither the used salt nor the stored hash, I would guess that a timing of the comparison of calculated and stored hash will not give any information at all, since every (even single bit) change of the password input will result in a completely different hash.
(This applies to every pseudo-random function, not only bcrypt. We actually need only the avalanche effect here.) See below for a more formal elaboration.

Other than this, normally the hashing process itself is included in the measuring, which takes much longer than the final comparison at the end, and thus will dominate the total measured time. I don't know how much this hashing time will variate, though.

Mathematical version:

  Now my question is whether this can be transformed into a
  "better than brute force" attack? Is there a possibility for
  an incremental attack, i.e. is it possible to construct a
  password with n+1 correct bits from a password with n correct
  bits other than using brute-force guessing?

So we have a function c_h(y), which is the number of leading bits
matching between H(s, y) and h. Let m be the total number of bits of H's output.

Assume we have an algorithm A which can do your attack, i.e. an algorithm which,
for a hash h (unknown to A) and a given message x with c_h(x) = n, finds a message x' with c_h(x) >= n+1, in time better than exponential in n.
(Simple brute-forcing the hash is exponential in n.) We can assume that this algorithm has O(1) oracle access to c_h(y) for arbitrary y.

Then we can from this construct an algorithm B which will do a preimage attack on a given hash h and salt s, i.e. finds a message z with H(s,z) = h. It works as follows:

The oracle for A is simply done by calculating H(s,y) and
comparing it with h, counting the correct bits until the first non-match.
We choose an arbitrary message x_0, calculate n_0 = c_h(x_0).
For each i > 0:

We pass x_(i-1) to A, and get back x_i with n_i = c_h(x_i) > n_(i-1).
if n_i = m, stop and return z = x_i.

The output of B is a preimage for (s, h).

As each n_i is larger than the previous one, this will take at most m passes through the loop, with each pass taking at most o(exp(n_i)) time, i.e. in total o(exp(m)). Thus we got a sub-exponential preimage-finding algorithm.

This shows that, assuming H is preimage-resistant, there can't be an algorithm which efficiently produces longer partial matches from shorter partial matches, given the match length as an oracle.

(I assume one can refine my timing approximation a bit better.)

Notes regarding the comments:

As the comment thread is getting quite long, I'll try to resume the important points here:

With weak passwords, an offline dictionary attack on password hashes
will become feasible, which would be our algorithm B. This is why
we want to choose the bcrypt work factor high enough.

Still, I see
no way to get from a fast B (offline preimage attack with given salt)
to a fast A (online partial preimage finder from hash prefix length oracle)
algorithm, only the other way around.

I expect that even for functions which are preimage-broken there
would be no easy way to get our online attack, as long as they
still fit the avalanche criterion.
Real-life hash functions are not really random (which is caused
by their iterative design), but this does not really affect their
suitability for password hashing, which works on inputs shorter
than the block size.
The important property here is preimage resistance, not collision resistance.
(Every collision resistant function is second-preimage resistant, and
second-preimage resistant functions are preimage resistant - though
we usually expect a higher resistance against (second) preimage attacks
than given by this reduction from collision resistance, due to the generic
birthday attack to find collisions.) This means this proof applies
to MD5 (which is broken collision-wise), as long as there is no preimage
attack.
The proof above does not rely on the hash function being a random oracle,
it just uses an oracle access to c_h(y), which abstracts the timing
measure for the


No, if you wanted to scan a whole subnet your computer is basically sending out packets saying

Who has 192.168.1.0?
Who has 192.168.1.1?
Who has 192.168.1.2?
Who has 192.168.1.3?

and this might be noticed should sufficient monitoring be in place.

A way to circumvent this is to run a passive scan using something like netdiscover. This can listen for ARP packets and output a list of all IPs encountered.


Should big companies publicly list their legit emails and links?

Opinion: They SHOULD use their own domain both as the from-address in mails as well for any links in any communication.
It's only for their benefit. This will help mitigate password stealing for their users, avoiding bad press in the long run.


Take a look at this paper here. They also provide the PCAP file used in the research here.

The password file should be stored at /data/data/com.whatsapp/files/pw.

However, if you are not root,  you may want to use this trick to access it:

Install Android SDK
Open cmd
Change your directory and go into 'Platform tools'
Type 'adb shell'
su
Press 'Allow' on device
chmod 777 /data /data/data /data/data/com.whatsapp /data/data/com.whatsapp/*

Also, you can use this application to retrieve the password (also needs root)


Is there a well-researched and user-friendly solution to the password problem?

The password problem is multi-faceted.  For this answer, I won't duplicate what others will tell you (your process looks fairly good, yet complex).

I will tell you this - the algorithm is the most important piece.

You can use a password of 81OTl*8tlxI+VqTZI7%wK however, if the place you have this password just stores plain text, ROT13, DES crypt, or MD2, MD4, MD5, NTLM, with or without a little salt, then oclHashcat can crack it in no time flat.  However, even Password1! with script and 100,000 rounds is more secure than 81OTl*8tlxI+VqTZI7%wK on crypt()...

Reference: https://en.wikipedia.org/wiki/Scrypt
(or for you "Wikipedia is not a reference" folks:  https://www.tarsnap.com/scrypt/scrypt.pdf)
https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-1ef4bb9c19b3
https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-and-argon2-e25aaf41598e (2019 revision)

This isn't an "end-user article" however, this can be used for "educating website owners on the server-side problem".


Should I log users in if they enter valid login info in registration form?

Unless other authentication methods are involved (for example 2FA, etc.), if a correct email and the corresponding password are sufficient and necessary to log you in, then I see no security issues. The reason is simple: the authentication and authorization process doesn't change. However, if for example 2FA has been enabled for an account and the second factor is necessary in order to log in, if you allow users to login from a registration form that only accepts email and password, you will introduce a weakness (because it will be possible to bypass the second factor from the registration form), unless of course you also check the second factor right after the registration of an existing user with 2FA enabled. This might make your app more complicate.
That said, I believe what you proposed is generally a bad choice for UX (User Experience) anyway. What happens if there are other fields in the registration form, and the new data is different from what is already saved in the account? Think of a phone number, for example. Are you going to update it in the profile automatically without a warning? Are you updating it with a notice? Or will you discard it? This problem will introduce steps and choices that will make everything more complicated, both for you (and your code) and for the final user. Also you will have to distinguish between users that already have an account but entered a wrong password, and users that already have an account and entered the correct original password. You can't just log them in without a notice, because their experience is going to be different (a new account will not behave in the same way as an established account, and will have different data and settings). Unless the users understand what you are doing, some of them might even wonder if there's a bug in your software and think: "Did it just let me log in because I used the right password, or would anybody be able to log in to my account with this registration process?".
So, as I said, I believe that this is going to complicate things both for you (and your code) and for the user. If you have huge registration forms and you want to avoid that users waste a lot of time when registering if they already have an account, then make sure you check their email address right away, in the first steps of the registration process, or in the background via AJAX, so the user will discover they already have an account before they start filling in all the fields.


This appears to be a false positive. Many of those IP addresses are indeed owned by Facebook, and the ports used makes it appear to also include Facebook's chat app. Your router is likely being just a little overzealous in marking incoming traffic as a DoS attack. In particular, you can see that each of these connections occur minutes apart from each other, while a true DoS attack could involve thousands of connections every second. These occasional spurious connections pose no threat to your network.


Having a code-signed binary, how can I tell if it's signed with an Extended Validation (EV) certificate?

The fact that it is an EV certificate appears in the certificate policy attribute that is shown in your image. The certificate policy identifies the rules under which the CA has issued them. In this case, it shows that digicert claims it was expended according to the policies with OIDs 2.16.8401.114412.3.1 and 2.23.140.1.4.1. Each CA assign its own OID to their different policies.

The client has a list of OIDs which it considers to be Extended Validation. Basically, while validating the certificate, it sees if the certificate was issued under a policy  which it has listed on an internal list of policies that it considers to be Extended Validation (additionally, it verifies that the CA that signed such policy is the one that provides such policy).

As for checking it yourself, you could copy the code for deciding if it considers it EV validation from Chromium code, for instance. Although the policies that are considered EV may differ between Chromium and Windows, though.


IPSec Domain Isolation with Windows Server

IPSEC can be configured using multiple authentication methods. I personally prefer using certificates from my internal CA over Kerberos. There are several devices I deal with (Linux, servers in my DMZ, etc) which would be difficult or impossible to set up with Kerberos. An offline IPSEC certificate request is much easier to work with.

The request statement makes it possible to use IPSEC with falling back to unencrypted traffic available. This is a good first step in starting with IPSEC. The require is exactly that - the traffic must be encrypted with IPSEC in order to be allowed. This is good for your most sensitive systems / services.

There are services, etc which you don't want to be covered by IPSEC. This includes anything public facing or which may need to be used prior the encryption being established. That would include DNS and a few of the AD specific services. I don't have a minimum list of services required to remain permitted unencrypted readily at hand. I'm opting to leave my DCs in request mode until I have the time to track that information back down.


What is the actual mechanism when we used VPN on HTTPS

Well, you're simply sending your encrypted web traffic through the VPN tunnel. The VPN doesn't care if it's HTTPS or any other protocol. They just forward your traffic.

So, if you visit an HTTPS site through a VPN...

Your ISP sees how you establish a connection to the VPN provider. They see the VPN server's IP which you're connecting to and can observe the handshake. Afterwards, they see how you exchange encrypted data which they can't decrypt or inject malicious packets into.
The VPN provider sees the IP of the website you're visiting. They can observe your TLS handshake with the web server and due to SNI they most likely also see the server's hostname. Afterwards, when you're interacting with the website, they only see you exchange encrypted data which they can't tamper with.

You'll probably also issue a DNS query which, if it is configured to go through the VPN, is only visible to the VPN provider and not your ISP. Also, this is assuming a correct setup with certificate checks. That is, your VPN client needs to verify that the certificate provided by the VPN server is legitimate (to ensure your ISP didn't tamper with it) and your browser needs to verify that the certificate provided by the website is legitimate (to ensure your VPN provider didn't tamper with it).

Somewhat related:

Can a VPN decrypt my SSL traffic? (They can't, unless you ignore certificate warnings.)


Attack vector for exploiting WhatsApp's retransmission "vulnerability"?

What does a real-life attack look like that would exploit this vulnerability?

Here is a possible scenario:

Alice lives in an oppressive government. She communicates with journalist Jonas over WhatsApp with the intent to leak information about a political scandal.
Afraid of being revealed, Alice one day panics and destroys her phone without telling Jonas.
A day later, Jonas sends her a message "Is it okay if I name Bob as the source?". Alice of course doesn't receive that message because her phone is gone.
The government instructs the telecommunication service provider to identify a new phone as having Alice number. They go back online, verify to WhatsApp that they own Alice phone number and announce a new keypair so that they can read any messages that are sent to "Alice" in the future.
Jonas' WhatsApp recognizes that Alice seems to be back online with a new key. Because the last message hasn't been transmitted yet, Jonas' WhatsApp will automatically resend that message and encrypt it with the new key. (If Jonas has turned on his security notifications, he will be told that Alice  has a new key, but he won't be asked if it's safe to re-encrypt the message for the new key.)
Government can now read Jonas' latest message and learns that Bob leaked the information.

Tobias Boelter explains this in a similar way in his blog post:

  Imagine you dump your phone into the ocean and only a month later you get a new phone. Then during this one month time period, some friends might've sent you messages. In WhatsApp, your friends phones are being instructed to automatically re-encrypt and retransmit. But they don't know if they are sending the messages indeed to you or the government. Then, and only if your friends specifically asked WhatsApp to do so, they will see a warning that there could've been something shady going on. Signal on the other hand will tell your friends something like "there might've been something shady going on. Do you want to resend your message?".

Currently, there is no setting in WhatsApp that needs a sender to confirm if they want to re-encrypt a message for a changed key if the message has not been delivered yet. However if the message has been delivered, the sender can't be tricked into re-encrypting it.

As I understand it, Facebook is concerned that adding a confirmation dialog for retransmission with changed keys impacts the user experience in a way that drives WhatsApp users away to less secure messengers, having an overall negative impact on people's security. On the other hand, Boelter argues that the added security of such a feature outweighs the minor impact on usability.


I'm not intimately familiar with the details of this vulnerability, and you didn't link to any further information about it, but just based upon the information provided here:

If your PHP code allows remote users to influence the contents of the Unix socket pathname (something that may be rare, but perhaps not completely implausible), then a malicious remote user may plausibly be able to use their influence on the pathname to exploit the vulnerability.


TFTP is a very weak protocol, from a security point of view: it has no provision for security or authentication, uses UDP for transport which makes it extremely easy to spoof, intercept, DOS or manipulate by anyone on the same network.

iPXE, on the other hand, does implement authentication, data integrity and security: you just have to set it up.


There is no need to use encryption since the information is not secret. The important part is instead to protect the information against modification (which is not even provided by all encryption methods).

Since both API's are provided by the same provider a way to do this is to have a secret only known to the provider and then use the secret and the exchange rate together inside a HMAC. This HMAC can then be created by API#1 and send together with the exchange rate to the client. The client will use the given exchange rate and the HMAC when calling API#2 where the server can compute a new HMAC using the provided exchange rate and compare it with the HMAC send by the client. If both match the rate was not tampered with. Implementations for HMAC are available in most common languages. See also Wikipedia:HMAC for more information.

If both API's are not provided by the same party then a shared secret can not be used. In this case one could use digital signatures: The provider of API#1 would create a key pair (RSA or ECC) and publish the public key of it. The private key would be used to sign all messages which need to be protected against modification, i.e. the exchange rate in this case. Everybody who got the public key would be able to verify the signature and thus detect tampering. For more see Wikipedia:digital signature.


Certificate works in Chrome + Firefox but not with curl ("unable to get local issuer certificate") with the recent cacert.pem

Does it mean the intermediate cannot be pulled properly?

While it cannot be said definitely from the few information this is a typical misconfiguration which results in what you see.

  But why does it work with the Browser?

Browsers try to work around such misconfiguration by using cached intermediate certificates from previous connections (Firefox) or even trying to retrieve the missing certificate based on the issuer information (Chrome). Other tools usually do not work around such misconfiguration.


Anonymizing IP addresses using (sha) hashes; how to circumvent rainbow table attacks?

As long as you are not storing IP addresses alongside other personally identifiable information, they do not have to be handled under GDPR rules. They only become sensitive when enriched with a user's name, email address, or any other such data. Just make sure that the systems limiting requests are separate from those handling logging in and user data, and you'll be fine. In this case, all you're really storing is a contextless number from a discrete set.


Determining the point of compromise on an infected web server?

Ah, the joys of shared hosting. You can be 99.9% sure that in this incident, another shared hosting service on the same server, which is running WordPress, was hacked by this automated script. This would answer the first part of your question.

The underlying question is 'how did somebody else's account being compromised affect MY account?'. If this GetMama auto-attack didn't run some kind of PHP exec() command to exploit a Linux vulnerability then there's some kind of permissions issue going on that BlueHost need to address. These things can get in to other accounts by many ways, including through shared database servers with incorrect user permissions specified.

(disclaimer - this is a general answer, I didn't google 'GetMama' at all)

All in all it's a prime example of the importance of keeping your webapps up to date. Especially popular packages such as WordPress or vBulletin as their wide-spread use makes them obvious targets. Keeping things up to date helps to keep your site safer and also helps you be a good neighbour by reducing the potential of trouble for other users. Same goes for people running the servers.

Best way to protect against this is to not use shared hosting. These days a low-spec VPS can be found for the price of decent shared hosting (~$30/m).


Have a read of the How to get into RFID auditing question as there are some very useful links there.

Contactless cards and RFID cards are just a small computing core with some limited functionality and a radio transceiver which not only powers the card when a radio signal is present, but also receives and transmits data within a small range.

The key usual difference is that RFID is usually used to refer to a card which will identify itself when queried, whereas the Contactless Card term usually refers to an RFID with some onboard storage for small payments without having to insert a card into a machine or type a pin, for example Oyster cards for travel payments on London Underground.

Risks around cloning are mitigated to a great extent by the cryptographic engine on the card - and Ross Anderson's team at Cambridge keep on finding new attacks in the lab, but the key risk over cards which have to be inserted is that an attacker only needs to be in the general proximity, and doesn't need to steal the card, reducing the difficulty of attack. The range, while supposed to be very short, can be increased by attackers using higher power equipment and higher gain antennas.

The new wave of Contactless Card functionality - enabling credit/debit card payments - just extends this risk a bit further by increasing the amount of funds which could be accessed.


I was tricked on Facebook into downloading an obfuscated script

This is a typical obfuscated JavaScript malware which targets the Windows Script Host to download the rest of the payload. In this case, it downloads what appears to be mainly a Chrome Extension (manifest.json and bg.js), the autoit Windows executable, and some autoit scripts which install them. All of these files are named with .jpg extensions on the (likely-compromised) server they are hosted, to be less-conspicuous.

The malware appears to be partially incomplete or otherwise underdeveloped or perhaps based off some other malware (quality is very low). Many of the autoit scripts don't actually do anything, and what appears to be a ZIP meant to contain a Firefox extension is actually empty. The autoit scripts are a ton of includes combined into a single file, but only one (ekl) actually has a payload at the end.

The one active autoit script which runs on infection replaces the Chrome, IE, and possibly other browser shortcuts with a shortcut to Chrome with the necessary arguments to run the malicious Chrome extension.

The Chrome extension is mainly how this malware is being propagated. It does some nasty things like blacklisting antivirus software domains, and sending Facebook messages automatically. Actually there was a webservice back end at http://appcdn.co/datajs serving some scripts which would be injected on any page a user visited based on the URL currently being viewed, which was how the Facebook messages were being posted. This service is now offline, likely taken down.

  Is this an exploit on Facebook?

Not exactly, more-like abuse of Facebook. Facebook's code hasn't been exploited, your friend just has an infected browser phishing their contacts on their behalf.

  Is it possible that my friend got a virus which targets their contacts by tagging them on malicious links?

Yep, that's exactly how this malware is spreading itself.

  Should I report this to Facebook? If so, how?

Yes, see How to Report Things in the Facebook help center.

Getting the following URL's taken offline by contacting their hosts would also be good.

http://userexperiencestatics.net/ext/Autoit.jpg
http://userexperiencestatics.net/ext/bg.jpg
http://userexperiencestatics.net/ext/ekl.jpg
http://userexperiencestatics.net/ext/ff.jpg
http://userexperiencestatics.net/ext/force.jpg
http://userexperiencestatics.net/ext/sabit.jpg
http://userexperiencestatics.net/ext/manifest.jpg
http://userexperiencestatics.net/ext/run.jpg
http://userexperiencestatics.net/ext/up.jpg
http://whos.amung.us/pingjs/?k=pingjse346
http://whos.amung.us/pingjs/?k=pingjse3462
http://appcdn.co/datajs

Unfortunately, CloudFlare still has not taken the userexperiencestatics.net URL's down though I contacted then shortly after posting this answer, and I don't know who is actually hosting these files. CloudFlare just emailed me to say they restricted access to the files, and says they will notify the host.

UPDATE:

After I and likely others reported the .jse URL to Google, they appear to have taken down the file. If you find any more copies, those should also be reported. It seems people have been receiving the files from numerous sources.

MORE INFO:

This malware and post is getting a lot of attention, so I'll add some more info to address people's questions:

  Will this file automatically run when downloaded?

Probably not unless you have configured your browser to do so. It is meant to trick you into opening it.

  Can it infect my phone, or non-Windows computer.

As far as I know, Windows is the only OS which can run this malware. As I mentioned, it uses the Windows Script Host. I don't believe even Windows phone is vulnerable, though I don't know much about Windows phone.

UPDATE ON RANSOMWARE:

Previously it was assumed the autoit scripts contained ransomware, however after further inspection this appears not to be the case. There is just a bunch of unused crypto function obscuring the actual payload, which I've mostly deobfuscated to this.

UPDATE ON CHROME EXTENSION:

The unpacked Chrome extension code can be viewed here. Details on what it did integrated above.

UPDATE FOR JSE SCRIPT:

My de-obfuscated comment_24016875.jse script can be viewed here.


What steps can you take to make offline cracking of SRP harder?

In SRP, the server stores a password-derived token, which can be used to guess the password in an offline dictionary attack (attackers tries potential passwords until a match is found). This is not a flaw of SRP: the server necessarily contains some similar password-derived data, regardless of the used authentication protocol. The magic of SRP is that no other place in the protocol yields such a password-derived data (even if the attacker tries to impersonate the server). But if the server itself is compromised (all its secrets are known to the attacker), then an offline dictionary attack is possible.

Strengthening this token involve the usual tools, i.e. salts and iterations (see bcrypt). In practice, this means that the output of bcrypt is used as "password" in SRP.


Exploit database for NVD vulnerabilities

Few sources I search for exploits (by CVE):

Exploit Database
CX Security
Vulnerability & Exploit Database
0day.today (accessible via tor onion service)
VulDB (not exactly for exploits, but helpful)

Do check this list for additional sources of vulnerability databases


How secure is to seed PRNGs with the sequences from CSPRNG?

This certainly looks like premature optimization.

A fast CSPRNG on a modern Intel CPU will output between 500 MB and 2 GB per second. Even if you have a quite random game which requires 100 random bytes per second per player (I can't think of a typical casino game anywhere near that) a single core will be able to generate random numbers for ten million simultaneous users.

Other operations, such as database access, the webserver etc. will be much more expensive than generating good random numbers. I recommend seeding a good stream cipher like ChaCha or AES-CTR from the system random generator instead of downgrading to an insecure PRNG. It's possible that the system random generator by itself is already fast enough.

Check eBACS for benchmarks of stream ciphers.

Using non crypto PRNGs like Mersenne-Twister for an online casino is a really bad idea. These generators don't aim an unpredictability. They only try to look random enough that their flaws don't cause any deviation from actual random data that breaks the using code by accident.

For example if you ran a scientific simulation with MT and with perfect random numbers and it gave different results, that'd be considered a flaw in MT. But it doesn't try to resist somebody who deliberately tries to predict the output.

As @CL. already said, MT is easily predictable once you've seen a few hundred outputs. Compare that with a CSPRNG which will be indistinguishable for true random numbers even after observing petabytes of data.


To what extent are supplementary yum repositories certified by CentoOS?

CentOS is a operating system. It can't certify anything.

If you are asking if the packages are cryptographically verified with a key that is part of CentOS: yes. The public key for this repository is part of a current CentOS installation

If you are asking if anyone will guarantee you that the packages in the repository fulfill any requirements you might have: no, no one does that

But you are using CentOS. No one guarantees you anything for your operating system anyway. If you need any legal security, you have to pay for a support contract. What exactly is guaranteed depends on your contract.


How do DoT and DoH facilitate fingerprinting by resolver operators?

TLS Resumption
TLS Resumption is a mechanism which allows the client to resume a recent TLS session so they can use the previously established session keys to continue encrypted communication and skip the key exchange step in the TLS handshake. However, it also allows  sessions to be linked together by the server, so it can be used to track the client over longer periods of time.
A similar problem is presented by TCP Fast Open. Clients can send a TFO cookie to reduce the round trips required to open a TCP connection. However, like TLS resumption, this can be used to uniquely identify the client and track it across sessions.
HTTP Headers
Another way to fingerprint clients would be through User-Agent, Accept-Language and Cache HTTP headers to infer information about the client such as the client version, locale and possibly some information about a subset of the client's history, as mentioned in RFC 8484.

Of course, it's possible to mitigate most of this on the client side, by not utilizing TLS resumption or TCP fast open, and not sending accurate HTTP headers, perhaps even randomizing them (although I am not sure whether any DoH/DoT clients take care of this or not).


Can encrypted data be safely dispose off by quick formatting?

Provided that your password is strong, and the laptop is set up to require your password on startup (ie it is not setup to auto-login) then your data will be protected.

It sounds though, like your concern is not about the encryption itself, but about rubber hose attacks, as per XKCD:

So what you're really after is plausible deniability that there is any data on the drive at all (ie you want to be able to say "What password? This drive is empty" and have them believe you).

To that end, a quick format will probably be enough to get through airport security because the laptop won't boot. But if the airport people become suspicious and seize your laptop then it will be quite clear to any forensic analyst that there is encrypted data on the drive, and they may mount a legal case in order to compel the password from you.

So it depends on the level of risk you're willing to take. Your options are, starting with the most secure:

Travel with no hard drive and install one / buy a USB stick and make a bootable OS once you arrive.
Fully wipe the drive according to the EFF recommendations.
Soft wipe (aka quick format) the drive.
Leave it as-is and hope they don't ask you for the password.


Can I buy a signing-valid certificate for internal use?

Some established CA will agree to sell you an intermediate CA certificate, but at a rather steep cost. There are several forces at hand here:

An "established CA" is "established" by virtue of having its root key included in the usual browsers and OS. The CA operator could achieve that by signing a heavy contract with Microsoft, in which he promised to apply very strict rules when verifying the identity of certificate owners. When a CA issues an intermediate CA certificate, it delegates its power. Bluntly stated, if you buy an intermediate CA certificate from an established CA, nothing technically prevents you from then issuing a fake certificate for, e.g., "gmail.com", that all Web browsers on Earth will accept as genuine.

Therefore, established CA have promised (with penalties in the millions of dollars) that if they ever give away an intermediate CA certificate to a third party, then they will do so only within a heavy contractual framework which would allow powerful legal retaliation, should that third party begin to issue certificates without all due care with regards to user authentication.
Established CA make money by selling certificates. They want to keep it that way. When you buy an intermediate CA certificate, it is to issue the end user certificates yourself, and therefore to cease to buy such certificates from the established CA. From their point of view, this is lost business. So they will recoup it by pricing the intermediate CA certificate heftily.

Also, it is too easy to underestimate the costs of operating a CA. A CA is 5% cryptography, 95% procedures. Procedures mean people, and paper, and time. That's expensive. Maintaining your own CA, be it an intermediate CA from some external established CA, or a full-blown root CA of your own, is hardly worth the effort for less than, say, a thousand certificates to issue per year. People often believe that a home-made CA is just a matter of writing a couple of scripts around OpenSSL; and they are wrong.


Google shows my site as hacked in their search results

According to Google, in the Google Search Console you should be able to find suspicious URLs on your site, that originated the message. If no URLs appear, your only recourse is contacting Google for an explanation.

After solving the error (or vulnerability: for example if you have a Magento Community Edition software v. 2.1.6 or below, you should upgrade), you need to request a new check from the Security Problem section of the Console.

The notice might appear even if everything is fine, if some components of your web site are obsolete AND they are vulnerable AND an update exists AND you did not install that update.

The most straightforward way to contact Google is not straightforward at all - not to my metric for straightness at least. You run the search, get your site with the problem, go to the end of the page and click "SEND FEEDBACK". Choose 'Send Screenshot' and activate the selector tool, border your result in yellow, and explain what happened. Include your email, specify that Google Admin Console is not working, and hopefully you'll be contacted (or maybe they'll silently fix the problem).


Meterpreter: How to invoke commands in a loop for each new connection

Metasploit scripting supports Ruby, so you could build your workflow around something like...
<ruby>
while true
  run_single("screenshot")
  run_single("sleep 300s")
end
</ruby>


I'll answer these separately:

  How can I check is extension/addon consist of malware code?

Usually browser addons exist as a file archive somewhere, within your browser's application files. You can find out where by doing a quick Google search. Once you've found the file, upload it to somewhere like VirusTotal. You could also extract the files (most plugins are just renamed .zip or .tar files) and manually dig through their code. Certain browsers also load DLLs as "browser helper objects" (BHOs), which can contain malicious code. These can be found and scanned in the same way, and Autoruns will tell you which BHOs are loaded into IE.

  Is it easy to detect if it collects sensitive data (like spyware), logging keystrokes and so on?

Depends on the malware. Keyloggers usually hook APIs related to processing keystrokes, which most AV software can detect or prevent. There are other methods though, so it's not possible to catch all logging mechanisms. Spyware almost always phones home at some point, so you can keep an eye out for unusual network connections in your firewall logs.

  Can AV recognize malware extension as "bad"?

Most can, yes. Some will only process executables (exe, dll, sys, etc.) on standard scans, but you can fix that by running a deep or full scan. On-access scanners should pick out known malware in any file the moment it's accessed.

  Can extension exploit browser vulnerabilities?

Yes, but sometimes it's not even necessary. In older (and crappier) browsers, a plugin is already native executable code running at the same privileges as the browser. Modern browsers tend to implement their plugins in a sandboxed scripting environment. There may be vulnerabilities in those scripting engines that allow the malware plugin to escape and escalate.


How do atom's apm and npm verify package integrity?

According to npm issue #6886, there is a system for validating the contents of packages via any checksum or hashing system.

Quote from GitHub user othiym23:

  npm has included validation of the package tarballs, via their SHA-1
  digests, since pretty much the beginning. It's worth pointing out,
  though, that this is intended as a verification measure to ensure that
  the package tarball has been correctly downloaded from the registry;
  it's not meant to protect against substitution attacks.

So, while the data is verified to be the SAME data that came from the npm server, there is no way of validating whether or not the code being delivered from the server is the code you expect (e.g. no system in place for validating the package with your own trusted hash).

There appears to be some checking of validation in the source code, however, the source also reveals that there is NO integrity validation for Git repository based npm package fetches.

You can find the logic for this condition on line ~120 in this file.


Why does Microsoft Authenticator app ask me to choose a number?

This is a way of closing the loop by ensuring that the phone owner knows the information provided by the website. In principle, it seems to add little benefit since, if you are entering your credentials on a phishing site, and that site is using your credentials to log in, it could channel back the presented number that you need to provide on the phone. (It would be a little harder than doing so asynchronously, but not that much)

This is different than eg. a prompt from a bank, where presenting/asking the amount to be transferred makes sense to avoid an attack where the amount of the transaction had been tampered with.

If an attacker knew your credentials and you always logged in at the same hour, this would prevent that an attacker logged in at the same time as you and you inadvertently gave access to them, but it seems extremely hard (maybe if you are aand the attacker was viewing your login screen?). Also, I'm not sure how do either Microsoft or Google react when receiving two concurrent login requests for the same account, they could deny both of them in that case.

A scenario where this would matter is if the phone bearer is different than the one logging in, so a number-choosing forces that there is a communication from the one logging in to the bearer, while a Yes/No question could be approved without paying much attention (oh sure, this must be Bob).

My suspicion is that this is implemented as a defensive approach, in order to avoid that people get used to always tap Yes and approve everything, perhaps even before realizing what they are doing. The number-choosing method forces the user to be aware of the actual application that is requesting access at this point.

Finally, even if this is only slightly more secure than a Yes/No question, its cost is so low that it makes sense that they implemented this.


Is there a way to "lock" a YubiKey after a period of inactivity?

Understanding @Joseph's point, I was still concerned...

I discovered that actually, simply quitting the Yubico Authenticator GUI will require the password set on the OATH applet when it's relaunched. It appears to store the OATH application password in memory, because ykman oath code asks for the password every time it's run.

Given this, it was very simple to create a small cron job which runs every minute, checks the idle time on the GUI and runs killall yubioath-desktop 2> /dev/null is the idle time is greater than a configured value.

This provides what I was looking for.


How do I import a GnuPG private PGP key into Symantec PGP commandline?

Actually this key is successfully imported and you can use it to encrypt data with it.

The "Validity" states do you have any evidence that this key was really created by its owner. It doesn't mean that it cannot be used. Check here for more details: http://www.pgpi.org/doc/pgpintro/#p17

The "(Joint key)" phrase is part of the key User Id.


I would say the biggest difference is that ArchPwn is not as actively developed. (EDIT:  see BlackArch,  this project was reborn!).  A lot happens in a year in the realm of security.  In fact in the last year a tool for cracking WPA-PSK called Pyrit was released and can be found on BackTrack.

Now the counter argument is that both Archlinux and Ubuntu have package managers,  and even though its a live CD you can really install anything or have  USB stick with your own tool chain.   It really depends what you are after. In fact no Live CD is going to have everything.  Invariably you'll need a USB stick.


Cryptographic hash functions usually have the property that slightly different inputs generate vastly different outputs. Any collisions should usually have very different input.

This property does not apply to most non-cryptographic checksums. Small changes can result in similar checksums, and in some corner cases some small changes can cancel each other out in a way that the same checksum is generated.

Changes in sourcecode are often quite small, so in the context of checking sourcecode changes the risk of collisions is quite high with non-cryptographic checksums. The version control tool git, for example, uses SHA-1 hashes as unique identifier for code revisions.

Why MD4 in particular? Well, you got to ask the ccache developers about this. It is a quite old tool, and MD5 wasn't standardized until 1992. It might be possible that MD4 was simply the most obvious choice which was available at the time this feature was developed, and later on nobody felt the need to replace the algorithm, because it did what it was supposed to be doing.


Odd url showing up in my pubsub stream, should I be concerned?

The URL they requested explains everything. Your Node.js server is open to the public Internet, listens on a port commonly used by HTTP proxies, and a service that scans the internet for proxies stumbled upon it and decided to test it by requesting an URL and seeing whether your Node.js would return the contents of that URL (if it does, then it's an open proxy and would get listed as such in their database).

This particular attempt doesn't seem malicious. Sure, if they discover you're running an open proxy they'll most likely use it for malicious purposes (spamming, etc) but their scan is merely requesting an URL and isn't trying to exploit a bug or DoS your server. That doesn't mean someone else wouldn't try to attack and compromise your server, DoS your app by filling up its DB with garbage data or exhausting the bandwidth of the server so the legitimate HTTP requests no longer reach it.

Now, you should still think about security and whether you actually need this Node server to be reachable from the entire Internet... you say the data you care about is coming from your internal network, then why don't you put the Node server on that same network ? That way you avoid unnecessarily leaking data to the Internet and your company network's edge firewall will protect you from scanning attempts since there's no valid reason for that Node server to be accessible from the Internet, and you're no longer vulnerable to DoS attacks from the entire Internet.

If putting the Node server on the private network isn't possible, consider requiring TLS client certificates to authenticate the legitimate data source so that a client needs to have a valid certificate before even being able to establish the TLS tunnel and issue HTTP requests. Also make sure to follow security best practices such as firewalling, hardening SSH (key authentication only, and change the port to avoid scanners filling up your logs), etc for the server itself. Your Node app may be the most secure app in the world, but it won't help if someone can become root by SSH'ing in with a bruteforced password or by exploiting some other app running as root.


Are clients blocking all incoming connections secure?

No, actually the users' behavior online is your biggest risk. If it was just running programs downloaded off the Internet or received in email attachments that would be easy, you could educate users or use technical means to prevent the file downloading and the email attachments.

The problem is your users will contract malware just by visiting web sites or just by opening PDF files! And this is much harder to deal with!


Obfuscating IDs for greater security in DB?

If you are attempting to be compliant and/or avoid the breach notification rule under HIPAA in the United States, then obfuscating data relationships within your database will not help you at all.

Under HIPAA, if data is encrypted you need not notify patients/insurance providers/etc about the breach.  However, encrypted means that it was encrypted using a FIPS 140-2 compliant cipher and only this encrypted data was obtained by the third party.

On a database, you can make use of tools such as transparent database encryption, or third-party encryption suites.  This would mean if someone got a copy of the database, it would be FIPS 140-2 compliantly encrypted, and thus not triggering breach notifications or other consequences under HIPAA.

However, simply having a hard to understand database is covered nowhere under HIPAA, and security-by-obscurity doesn't win you any points on a CMS audit...even if you explain obscurity is a "compensating control" for a HIPAA requirement.

Also while security typically means keeping unauthorized individuals out, the next worst thing to be able to happen to an organization keeping PHI data is losing that data.  Having a DB with complex relationships makes it easy to lose that data, and integrity of your data should be considered a security concern when dealing with HIPAA.

Note that transparent database encryption or other on-line encryption methods will do little against the online compromise of the database, e.g. through SQL injection.  If someone gets a DB dump by running SELECT * statements, this data wouldn't be encrypted.  For this, youl'l need to secure/segment your database users and also look into best practices for securing the frontend web application.

In short, encrypt the database somehow; but DB encryption should only be a small part of a larger HIPAA compliance strategy.  Security by obscurity, however, should not be any part of your security strategy.


For how much time should I randomly move the mouse for generating encryption keys?

The PRNG in the host machine feeds on hardware event for randomness. When you move the mouse, it sends "move events" to the PC, where a "move event" is like "hey, PC, I just moved 0.58 cm up and 0.31 cm left". A typical rate would be 15 move events per second (gaming mice have a higher rate). On the OS side, the amount of movement in each direction, and the exact time at which the event is received, will be used as "entropy".

The bright thing about entropy is that it just adds up, as long as you use a cryptographic hash function to mix it up into the entropy pool. The OS does that. About 128 bits of entropy are enough but the paranoid will like to go a bit beyond, if only to win at games of my-entropy-is-longer-than-yours. It can be assumed (a very conservative estimate) is that each move event will yield at least one bit of entropy (which means that if an attacker tries to predict the time and amount of the next move event, he will do no better than exhibit two equally probable events). So you will have at least 15 bits worth of entropy per second, i.e. 128 bits of entropy in less than nine seconds.

Therefore, it is not needed to torture your mouse more than a dozen of seconds. Moving the mouse for one minute is already total overkill.

(Since the OS began gathering entropy since boot time, and feeds on more hardware events than just the mouse, it actually already has more entropy than needed, and the whole dancing mouse thing is more ritual and psychological than scientific; it makes you feel secure more than it actually adds to real security.)


Way back in 1978, Robert Morris and Ken Thompson published the Unix "crypt" password scheme with two innovations that are crucial for password hashing: salts and iteration counts.  Without a salt, hashes are very vulnerable to hash tables and rainbow tables.  Even with a salt, iterations are also needed to prevent very quick brute-forcing of most any password with 8 or fewer characters, to say nothing of simple variations of dictionary words.  How long does it take to actually generate rainbow tables?

So please use a real hash designed for passwords - i.e. one that is slow and salted.  Some good candidates are:

bcrypt
PBKDF2: Rfc2898DeriveBytes Class (System.Security.Cryptography)

You can tune them to not take up too much server time, but people don't authenticate very often, so don't be stingy.

See also: Password hashing - IT Security


How to perform a security audit for a PHP application?

I suggest taking a look at the following links:

PHP Security Audit HOWTO
Spike PHP Security Audit Tool
Zend Application Security Audit
6 Free PHP Security & Auditing Tools


What can I do to prevent my web browser from accessing local files?

In answer to the question there is no global way to stop access to local files for ALL browsers via the address bar or via a web link.

You may though be able to block these links via your AV or anti malware software. As many have black list style options.

With IE, as it is Windows based, there may be ways to edit the registry or by using Local Group Policy.

A small caution note. By blocking local file access it may cause some minor usability issues. Such as downloading a PDF and trying to then run it in a browser (for example chrome).


Symmetric Encryption: Key + IV: What to do with the IV?

Either prepending or appending the IV is standard practice. The IV needs to be unique (with a given key) and for some cipher modes also needs to be unpredictable, but it does not need to be secret; sending it in plain text alongside the ciphertext is fine. If you don't have a handy way to separate the IV and ciphertext in your transmission/storage system, just putting it either before or after the ciphertext is fine as long as the recipient knows where to expect the IV to be and how long it will be.

I'm a little concerned by the mention of "calculating" the IV, though. The IV should be the output of a secure random number generator, nothing more. While there might be calculation involved in the RNG, to you it should be a black box that spits out numbers suitable for use as symmetric keys or IVs.


Android disk encryption is based on dm-crypt and is a full-disk encryption, meaning everything is encrypted using the same master secret. This is different from approach employed by iOS where different files are encrypted with different master secrets based on their protection classes. Effectively, all files on Android-encrypted disks share same protection class.

For older versions of Android (before 5.0) it was fairly easy to bruteforce the PIN so the protection wasn't great and I would rate it to be on-par with NSFileProtectionNone class in iOS.

5.0 introduced improvements to combat offline bruteforce and now whole thing is much closer to NSFileProtectionCompleteUntilFirstUserAuthentication. But please note that because Android's disk encryption is FDE and there's only one master key, it will never be equivalent to NSFileProtectionComplete — because Android won't be able to purge master secret from memory when user locks the device (otherwise none of background services will be able to access any data).

There is an excellent write-up on the Android FDE here (and if you're into Android security in general that blog offers tons of valuable information).


Is there a difference that financial instutitions can see between a VPN and a local IP address?

If the only criteria is your IP (using GeoIP for example), you are safe and the server will not be able to determine that you are using a VPN. NAT is probably used so the VPN gateway replaces your VPN-internal IP with its own, which is what any server you contact will see.

However, if they really try, they could lookup that IP and maybe find out, that this is a server, instead of some IP dynamically assigned to private households. But it's entirely possible that you belong to a company in that country and use this server as a proxy/VPN-Gateway.

In conclusion, if they don't try really hard, I couldn't think of a simple way to reliably determine whether or not you are using a VPN. Thinking twice, using a VPN is not even enough for them. They would want to know, whether you actually are in this country which is even more difficult.


Here's the list of best practices in securing RESTful API.

Always Use HTTPS - Traffic must be encrypted
Never expose information on URLs - as this can be captured in web server logs, which makes them easily exploitable.

https://api.domain.com/user-management/users/{id}/someAction?apiKey=abcd123456789
Consider Oauth
Adding Timestamp in Request - This will prevent very basic replay attacks from people who are trying to brute force your system
Input Parameter Validation - Put strong validation checks and reject the request immediately if validation fails.
Use Auditing and Logging - Any subject or entity can be audited

For more information, OWASP Provide a cheatsheet found here.


Any advantage to securing WiFi with a PSK, other than to keep out unauthorized

As I understand it, there is a benefit. WPA2 will generate a different session key for each association. That means that each node will still have its own encryption key. Without capturing the all four packets at the start of a session, a session cannot be decrypted. See Wireshark's documentation on this matter.

That benefit is limited, however. Attackers can force disassociation and anybody capturing a full association will be capable of decrypting everything from there forward.

Edit: It was suggested that I also point out "Hole 196" to you, which affects both PSK and enterprise authentication.


prevent unauthorised access to a method on an unauthenticated controller

If you don't have any authentication and authorization ("unauthenticated controller") then there can be no such thing as an unauthorized access: i.e. every access is allowed. And, what does not exist cannot be prevented.

If you could defined what unauthorized access means in your use case you might be able to add some authorization which prevents it.


First, movies are unrealistic in these regards.  It's no different than the "realism" of zooming in on security cameras and cleaning up the images.  It's just not realistic, but it makes for good entertainment and helps with plot advancement.

However, that said, there are plenty of people with easy-to-guess passwords.  I know plenty of otherwise intelligent people who don't bother with good passwords, don't change them frequently, etc.  Intelligence is no deterrent to bad password management, and therefore, super-villains and bad guys are just as likely to have easy-to-guess passwords.

If I were to try to crack into an account without brute force, I'd start with the basic easy-to-guess passwords, and count on the stupidity of the people I'm trying to hack. Or I'd resort to social engineering.  "I'm from the helpdesk and I need to get rid of a virus on your PC.  Can you give me your username and password so I can log in and do it?"  (You'd be surprised how many people fall for this.)

An easy way to induce "willing suspension of disbelief" for the sake of password cracking in the movies, I tend to favor the "weak password" scenario as it's the most realistic.