Does naming sensitive things discreetly provide protection?

Giving non-obvious names to things is akin to security through obscurity which is usually frowned upon in these parts. Problem with that kind of security is not that it does not work; indeed, it has some value, which was demonstrated many times through History (e.g. that's why a tank is called "tank" and not "armored chariot"). But you cannot quantify security through obscurity. You cannot know "how much" security it buys you; and, in particular, you cannot know whether it works at all (and though it often works well, it also often fails spectacularly).

Therefore, when thinking about risk management, the value of non-standard names must be considered low. This would not be a problem if it could be done "for free"; but non-standard names have a huge hidden cost: if they confuse attackers, they are likely to confuse sysadmins too. It will siphon out thinking time and resources, and will increase reaction latency if trouble arises.

Really, in IT security and in IT in general, descriptive names are a must-have.


Edit: As the question is a little unclear there might be a misunderstanding. From my point of view there are 2 possible answers:

GHIDRA does not offer a debugger for other binaries currently. (It is a planned feature)
GHIDRA has a debug mode to debug GHIDRA itself. This debugger is even
accessible from the network, as the exposed port is not only locally bound.

Hacker Fantastic on Twitter:

  Ghidra opens up JDWP in debug mode listening on port 18001, you can
  use it to execute code remotely ♂.. to fix change line 150 of
  support/launch.sh from * to 127.0.0.1 https://static.hacker.house/releasez/expl0itz/jdwp-exploit.txt


Is there a good reason (and what can it be) to require DAC restriction on IPC in addition to SELinux rules?

World-writable files are pretty much considered bad in all but very specific scenarios.  If there is no legitimate reason to have a file wide-open for the world to read/write to, it's best practice to lock it down.  Nearly all security audits will mark a failure for world-writable files... period.  And remember, in the UNIX world, everything is a "file".
Very few, if any, security audits will take specific selinux policies into account.  If they do, it would be in addition to native OS controls.  And by native, I mean typical UNIX file-permissions.  Many of these tests run across multiple UNIX platforms... Solaris, AIX, BSD, and Linux.  A linux-specific feature like selinux is unlikely to be taken into account.
Files should be owned by the functional account that the application runs as, with permissions limited to the functional owner and it's group, and access limited to those only (in most cases).
Your customers concern may not be tied to a specific threat model as much as it is simply considered best-practice and the ability to pass an audit.


What wrong with this system to proactively check if customers' passwords have been found in a breach?

I think what you are pursuing is quite ambitious but it is overkill.
In my opinion you should simply:

enforce a minimum level of password complexity
add two-factor authentication (2FA) - this will make up for weak or compromised passwords
if possible make 2FA mandatory or try to enroll as many users as possible
devote your free time toward tightening and auditing your systems - you may have some vulnerabilities present, that could nullify all your security efforts

So the answer is not to rely on the password alone for authentication purposes.

Checking the password supplied at signup against pwnlists is a good idea. Do it offline, that is against password lists that are  stored on a local drive. Do not submit the password to an online service for verification.
You can repeat this check whenever the user changes their password.

Regarding implementation of 2FA you have a number of options. It would be good to offer some choice, for example many users could be satisfied with a Google authenticator but others may more comfortable with an alternative solution.

SMS is not considered safe these days but it depends on the value of the assets you are trying to protect.


Using MySQL's built-in functions for encrypting and decrypting information is generally not recommended for exactly the reason that you described - MySQL is often configured to log queries.  If that's the case, the plain text data (and the encryption/decryption keys!) are written in plain text to the logs!

Having said that - If you must use aes_encrypt and aes_decrypt to encrypt the information that you are storing in your database, then you should disable the logging.  See http://dev.mysql.com/doc/refman/5.7/en/query-log.html for information on how to do that.

If your MySQL instance is running on a host that does not allow you to disable the logging, then it may be time to host MySQL yourself (which is not hard to do on a VPS).

Last but not least - statements such as ... where aes_decrypt(fieldname, key) like '%xyz%' are going to be sloooowwww when your tables start getting bigger, because MySQL will have to decrypt the data in each row and apply the like comparison.  Both of these operations (the decryption and the like) are fairly resource intensive, and indexes won't help.


Can anyone help me determine if this is something I should be concerned about?

Someone is trying to exploit a vulnerability on your server. References to cmd.exe, System.Net.WebClient and %SystemRoot% indicates this exploit is intended to a Windows server.
It shows your server returning HTTP 404, with 2111 bytes on the response (those last 2 values on your log). That means your server does not have the vulnerable /public/index.php file, so no damage was done on this case.
Your websocket probably is dying because you aren't properly processing unexpected input, and this is a MASSIVE SECURITY ISSUE (bold capitals because I cannot use blinking red text font). Failing to detect malformed input and reacting to that is the source of countless exploits.
If you don't know much about security, you can be sure that your server will be hacked sooner or later. Take your server offline, install a Linux VM on your desktop, and train on your VM first. Read articles on Linux hardening, on securing Nginx and Django, on secure coding. Your server can be a threat to anyone on the internet as soon as someone hacks it and turns it into a hacking platform to launch attacks.

nobody else is using this server currently

As soon as your server is reachable from the internet, that statement is not true anymore.


Yes, it does make sense. HTTPS does nothing to protect you against CSRF attacks. You would carry out an CSRF attack like you would against a HTTP enabled website.

Take a look at the CSRF description from OWASP to understand how it works. It will be obvious that the encryption of the communication channel is irrelevant for this type of attack.


There are a few things to unpack there, so I'll start with the following points:

Port 443 is usually used for encrypted HTTP (HTTPS) connections. It does not have to be. Web servers can be configured to listen for incoming connections on any port, HTTP messages will be transmitted and received just fine, and the TLS/SSL handshake will complete just fine. 443 is of course the standard though and used the majority of the time.
TLS/SSL is separate from HTTP. It just so happens it's really useful and widely used "on top of" HTTP. TLS/SSL is also used for video chats, messaging, secure FTP connections, etc. Simply, it's a method of securing communications. HTTP is just the most common type of communication secured.
Some of the details of the TLS handshake and how it's established a browsing session will use HTTPS instead of HTTP is explained will in this CloudFlare article and this Medium article. It all starts with the Client Hello message sent to the server. I've included an example of this message below, but it was originally hosted on GitHub.

Client Hello Message
 *** ClientHello, TLSv1.2
    RandomCookie: *** ClientHello, TLSv1.2
    RandomCookie: GMT: -1892413556 bytes = { GMT: -351008774 bytes = { 169, 131, 204, 213, 154, 96, 7, 136, 43, 142, 232, 138, 148, 171, 52, 226, 155, 202, 145, 57, 210, 132, 227, 182, 67, 222, 161, 28, 20 }
    Session ID: 239, 10, 92, 143, 185, {}
    93, Cipher Suites: [Unknown 0x8a:0x8a, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
    ………………………………………………

Hope this helps!


Do I have to block UDP ports when I launch my own server with a public IP?

10/udp open|filtered unknown

In NMAP lingo.

"open" means that a service appears to be running on the port.

"closed" means that the port appears to be unused.

"filtered" means that traffic to the port appears to be being filtered out by a firewall.

For regular TCP scans NMAP can distinguish between all these states because the TCP implementation in the operation system will always respond to a connection attempt either positively or negatively.

For UDP scans the OS will respond to packets sent to closed ports but for open ports the OS will simply pass the packet to the application silently. The application may or may not respond.

So for UDP scans NMAP can't tell the difference between a port that was filtered by the firewall and a port where the packet was delieverd to the application but the application didn't respond. Therefore it reports lack of response as "open|filtered".

  But i do not understand why nmap response "closed" on rule which is "allow" (in the udp port)

Because the packet makes it through the firewall but is rejected by the UDP implementation as no service is listening on that port.


Why is it a bad idea to use plain oauth2 for authentication?

Note: If you are looking for something like OAuth2, but for authentication, you should
  use OpenId Connect instead.

OAuth2 is meant for a user to authorize an application to load the user's resources from some resource provider. In other words: OAuth2 is a mechanism for delegation of authorization. The protocol does not support authentication (although it is commonly misused for exactly that).

The security hole is in the assumption you make in the 5th bullet point.

You say:

  Site A asks site B for Sally's user_id and logs her in with that ID

While in reality it should read:

  Site A asks site B for the user_id from the user-data that the access_token grants access to.

Figure 1: OAuth flow for (confidential) clients.

If all goes as planned, the access_token is, indeed, from the user you redirected to B for authentication. But: there is no guarantee that is the case. In fact, any (malicious) website that the user has previously granted the right to access the user's data (using OAuth2 with B), can get a valid authorization_code from B and send it to you, in bullet point 3.

In other words, if I run a website which asks users for their permission to access their resources at B using OAuth2, I can impersonate all those users at all websites which misuse OAuth2 (with B as OAuth2 Authorization server) for authentication.

The 'problem' with OAuth2 is that the authorization_code is not generated for a specific client_id. So if you receive an authorization_code, you can not be sure if B issued the authorization_code you received to you, or to some other service. Which is deemed acceptable for authorization but is absolutely unacceptable for authentication.

Update:
As to your comment:

  (and I restrict A to only accept one from users it previously redirected to B, but this is still unauthenticated)

I believe that you are here adding an extra precaution, which is not mandatory in the OAuth protocol. As such, it cannot be relied upon.


Is there a good place to find WAF rules tested?

In my experience you can't apply a generic set of WAF rules and suddenly be immune to OWASP Top 10 issues. You may find a compilation of WAF rules of known payloads for CVEs in Tomcat, or in nginx. Really though, once you patch your application you don't really need the WAF rules for CVEs that you're no longer vulnerable to.
There is value in WAF rules for 0-days; that is vulnerabilities that you have not had the opportunity to patch. I imagine there probably are security companies that offer services where you tell them which technologies you use and they will update your WAF rules the same day that a vulnerability goes public, but I imagine those services are expensive and hard to find; I'm not aware of any. This is also becoming a bit of a product recommendation, which is off-topic here.


Is it correct to say that the attempts of brute force per second will
  be twice faster if I have a quad core processor instead of a duo core?

Hashcat is multi-threaded so it will be faster with a quad-core but I don't think it will be twice as fast exactly.

  Which role does the RAM play in increasing the attempts per second?

Hashcat stores dictionaries in memory, so the more RAM you have the less swap needs to happen.

Ok so I went ahead and ran a little experiment, here are the results (I did not let the full benchmark run, so only the first few algorithms are tested). Here is the table for MD5:

| CPUs |  RAM | Words per Second |
|:----:|:----:|:----------------:|
|   1  |  512 |      13.59M      |
|   1  | 1024 |      12.47M      |
|   2  |  512 |      25.01M      |
|   2  | 1024 |      26.54M      |
|   4  | 1024 |      36.22M      |

Hashcat benchmark with 1 cpu and 512 MB RAM

Hashcat benchmark with 1 cpu and 1024 MB RAM

Hashcat benchmark with 2 cpus and 512 MB RAM

Hashcat benchmark with 2 cpus and 1024 MB RAM

Hashcat benchmark with 4 cpus and 1024 MB RAM


Can a bluetooth speaker contain malware?

It is technically possible, because a Bluetooth device will likely contain firmware and a small CPU (so it's not just a dumb variable resistor and speaker driver). In a purely theoretical sense, it would be possible for malware in such a device to spread by exploiting a bug in the Bluetooth protocol to gain code execution or unauthorized access to another Bluetooth-capable device. However, the chances of this are so slim as to be utterly negligible. There are better ways to infect someone. You can safely disregard a Bluetooth speaker as a malware infection vector.

Regardless, it is not a bright idea to connect to something random you see lying around.


Building a web application security focused team

Cigital's Building Security In Maturity Model (BSIMM) is a detailed study of software security initiatives in 67 organizations. All BSIMM participants have an internal group devoted to software security called the Software Security Group (SSG). The BSIMM FAQ describes the role of characteristics of the software security group (SSG) at http://bsimm.com/facts/.

According to the BSIMM FAQ the "SSG size on average is 14.78 people (smallest 1, largest 100, median 7) with a "satellite" of others (developers, architects and people in the organization directly engaged in and promoting software security) of 29.6 people (smallest 0, largest 400, median 4). The average number of developers among our targets was 4,190 people (smallest 11, largest 30,000, median 1,600), yielding an average percentage of SSG to development of just over 1.4%."

Gary McGraw, Sammy Migues, and Jacob West discuss the rationale and benefits of the SSG, particularly in the context of an comprehensive software security program covering the software development life cycle. They found the "percentage of SSG to development of 1.4% in the sixty-seven organizations we studied. That means one SSG member for every 71 developers. The largest SSG was 27.27% and the smallest was 0.03%."

  Though none of the sixty-seven SSGs we examined had exactly the same
  structure (suggesting that there is no one set way to structure an
  SSG), there are some commonalities we observed that are worth
  mentioning. At the highest level of organization, SSGs come in three
  major flavors: those organized according to technical SDLC duties,
  those organized by operational duties, and those organized according
  to internal business units. Some SSGs are highly distributed across a
  firm, and others are very centralized and policy-oriented. If we look
  across all of the SSGs in our study, there are several common
  "subgroups" that are often observed. They are: people dedicated to
  policy/strategy and metrics; internal 'services' groups that (often
  separately) cover tools, pen testing, and middleware
  development/shepherding; incidence response groups; groups responsible
  for training development and delivery; externally-facing
  marketing/communications groups; and, vendor-control groups.

For more about this issue see Gary McGraw's informIT article 'You Really Need an SSG' at  http://www.informit.com/articles/article.aspx?p=1434903


Will making HTTP cookies unique to a given website make cookies aligned with the strictest privacy guidelines?

owners of website Y could read what a visitor has searched for or had done in website X.

No, it's not. A cookie set by www.example.com cannot be read by www.another-example.com. That's a fundamental property of cookies: they are tied to a domain. Some are even tied to a subdomain, making a cookie from one.example.com being unable to be read from two.example.com.
What happens is that lots of sites will use some ad network to display ads. And those ad networks (for example, adnet.net) will receive a request with a special header: Referer, and that header says you are coming from example.com. And adnet.net can set a cookie giving you an unique ID.
So if you access example.com, and they use adnet.net as their ad-provider, your unique ID for adnet.net is sent to adnet.net and the Referer header says it's coming from example.com. They will record on their database that you accessed example.com, another-example.com and any other site you accessed and happened to have ads from adnet.net.
No cookie from adnet.net can be read either by example.com nor another-example.com, but adnet.net knows for sure you accessed both of them. And not only ads. A lot of sites are built using JQuery, and to not have to host jquery.js they just use a CDN and link that file directly. And the CDN too receives a request with Referer header, and the CDN can set a special cookie with an unique ID on it.

Will making HTTP cookies unique to a given website (so other websites won't be able to access it) make cookies aligned with the strictest privacy guidelines (or will there still be a privacy and maybe also information security problem)?

It won't make any difference, because your cookies cannot be read by anyone else. What you can do is to now have any external resources (so host all your images, all scripts, all ads). This way nobody can know your users by cross-referencing ad network and CND cookies.


Why, after a certain character limit, are larger passwords labeled as "weak" on some sites?

Password strength meters are notoriously weak:

  New research from Concordia exposes the weakness of password strength
  meters and shows consumers should remain skeptical when the bar turns
  green.

In general, adding a character to a password will not make it weaker. There are only specific situations where this isn't true. For example, MyPasswor is probably a stronger password than MyPassword. That doesn't mean that adding a character always makes it stronger. For example, bcrypt has a maximum length of 56 bytes. (Note that that is bytes, not characters.) Characters added beyond that length are simply ignored when the password is stored.

As a general rule, just create random passwords using a trusted password generator or diceware, and don't worry about the silly strength meters.


How to know if a file is decrypted or not

You really can't, if you're just encrypting / decrypting text.

If you know that the encrypted string is "kdo" and the encryption method is a Caesar shift, the plaintext could just as easily be "IBM" as "HAL". You'd have to have some idea of what the plaintext "looks like". For instance, if you know the plaintext is the name of a Stanley Kubrick character, you'd have a decent idea of which one it should be.

If you have a longer string, it's much easier to narrow things down. A large text file has much fewer intelligible results than the three-character example above. But you'll still need to determine whether it's decrypted yourself.

On the other hand, if you're decrypting an entire file in some specific format (.docx, etc), you can be reasonably sure the file is decrypted if the parsing program (Word, etc) can read it.


Chrome incognito forensic analysis in case of abrupt shutdown

Swap / pagefile
If memory pressure on the target machine is high, there is a chance that some pages of memory from the browser process are swapped out onto the disk (the pagefile on Windows and the swap file on Linux). On modern systems with plenty of RAM, very little, if anything, is swapped out. Additionally, this swap space is sometimes encrypted, with the key kept only in memory. The key is random and so cannot be cracked. Newer versions of Windows may do this by default. Older versions require the user manually enable encryption of the swap space. When the swap file is encrypted, or when the disk containing the swap file is encrypted, then shutting the computer off (whether naturally or by unceremoniously unplugging the device) will result in the key vanishing.
Downloaded files
Whenever a download prompt is opened, the file to be downloaded starts automatically being saved, usually with the .crdownload extension. This downloading occurs even if the user cancels the download or does not even accept it. This is done as an optimization to improve apparent download speed. If the user does not specify a filename to save it as and begin the download, then the temporary file will be deleted as soon as the prompt is closed. You may be able to infer what sites were visited by looking in unallocated filesystem space for these remnants.
There may be reasons a user has inadvertently triggered the download prompt. Some links, when clicked, access a resource where an HTTP header causes the file to be downloaded rather than be opened inline in the browser. Additionally, a user who is used to using browser shortcuts may accidentally press ctrl+s, which opens a download prompt for the current page.
Summary
Incognito mode makes an effort to not save anything persistently to the disk. This means there will be no cookies, no local storage, no history, etc. If you do not have access to logs from the ISP or anything similar, you will not be able to determine what sites have been accessed if the target's computer where the incognito browser is running has shut down. Note that this will be even more difficult if encryption is being used, since that will also protect swap space or temporary files.
In all these cases, you should make an exact forensic copy of the storage device and keep a strong cryptographic hash of it elsewhere to ensure it could not have been tampered with. Unless you clone the disk in this way, there will be the risk that the computer will have powered up automatically (e.g. due to Wake-on-LAN), rendering obtained evidence potentially inadmissible.


Is it at all possible to store Windows Sticky Notes in a secure manner?

It depends.

Full disk encryption will protect the sticky notes (and everything else on your hard drive) when the computer is turned off. However, it will not protect you from someone taking a peak while you are on a coffee break. If that is a requirement, you'll have to get them to use something else.

What your users really want is probably not sticky note. What they want is convenience. You will have to find another solution that is even more convenient, and take some time to teach them how to use it. For instance, a password manager could autofill the passwords for your users, so you don't even have to do the copy paste!

But convincing people to change habits is hard, so don't expect it to be easy.


When you enable 2FA, why is your second factor required to reset password?

This is a security measure that is implemented independently of 2FA. Many places require you to enter your current password when you want to change your password. Password reentry may also be required to change contact information and account recovery options.

The reason for this is to prevent unauthorized changes. If it is possible for users to leave a session unattended, then it is possible for another person to make changes to the account. The most sensitive settings relate to authentication, recovery, and contact information since those could grant ongoing access to a malicious actor.

In order to mitigate the risk associated with unattended sessions, most services implement an idle timeout, reauthentication for critical operations, or both.


If you want to check the basic functionality of a cryptography engine, throw a good selection of inputs at it, and check that it returns correct results on these inputs. If your sample is well-chosen, you can have confidence that the engine is functionally correct.

Many cryptographic algorithms based on mathematical structure (typically, public-key algorithms such as RSA) have methods to get some confidence that the result is correct without doing all the work. For example, if you run a computation that is based on operations modulo a large integer, you can perform the computation modulo a small integer and check that the result is correct modulo that small integer¹ — a generalization of casting out nines. This technique is known as wooping. Such checks can work against malicious bignum libraries if you test with enough random small numbers. However, you can't always do this; for example, if there was a way to check a cryptographic digest that was cheaper than computing it the long way, the digest algorithm would be seriously broken. I don't know of anything comparable for symmetric encryption algorithms.

If you want to know whether the cryptographic engine is secure, that's a completely different matter. The engine might be leaking data through side channels, and you cannot notice this by testing. You can only notice this by very careful study, preferably open-box. Similarly, the generation of random numbers cannot be tested, and is hard to get right; you can gain some measure of confidence with statistical tests, but not all statically sound random number generators are good enough for cryptography, which requires unpredictable random numbers. Here are some examples of vulnerabilities which can be very difficult to detect, and are practically impossible to detect if they are deliberate backdoors:

The random generator has a low entropy: it returns random numbers that are predictable with an unreasonably high probability. Example (accidental): the Debian OpenSSL vulnerability.
The engine leaks confidential information such as RNG output or key material through its response time. (This is an example of a side channel, there are side channels other than time: power consumption, radio emissions, etc.)
The engine leaks confidential information through normal channels in an undetectable way, thanks to a subliminal channel. For example, every time the engine generates a random nonce (an IV for block encryption modes, RSA padding, the signing parameter k in DSA, etc.), the n-bit random value is in fact an (n-1)-bit random value plus a bit of the key encrypted with a secret key.

Cryptographic engines can be certified to conform with security standards such as Common Criteria and FIPS 140. Excluding “trivial” certifications such as FIPS 140-2 level 1 which don't really say anything about security, a certification takes several man-months and is performed by experts. Even if your crypto engine is certified, read the certification carefully: most certifications only vouch for the engine if it's used under very precise conditions, and only against attackers with limited means. And of course in fine the certification is only one professional's opinion; certified products can and have been broken.

¹  I'm simplifying quite a bit. Read about it in Sami Vaarala's lecture notes or in Bruce Schneier et al's Cryptography Engineering or in Jurjen Bos's thesis.


Can a network admin see my computer's screen if I'm logged into their wifi network?

Your "screen" includes many elements that never get transmitted over the network, so there is no method by which anyone on the network could see those elements. For example, if I set my desktop wallpaper, no one on the network can see that.

Might it be possible to see a user's browser window (i.e. reconstruct a clone of the traffic to the computer)? Yes, under certain circumstances. By having access to the network, it is possible to capture the packets and then reconstruct them page by page or update by update. But, the traffic would have to be unencrypted (no SSL/TLS or VPN tunnels).

All this assumes that the malicious network has not also installed something on the computer.


Does a webserver need an antivirus software installed?

There are a few points to consider here.

First, AV is not a fail-safe, catch-all mechanism for any malware. Even ignoring the blurred line between AntiVirus and AntiMalware (these engines function differently, even if they are packaged in a single product), there is no AV/Antimalware product that will catch customized, targeted attack code. So, if that is the threat you are trying to protect against, you can just as well forget that.

Secondly, if you are accepting file uploads from users (especially essentially anonymous users), you should play it safe and go for defense in depth - even it's trivial to get around AV, you can at least block the low hanging fruit - and the "innocent" victims who continue to spread the payload unknowingly.

Third, if you want to play it super-safe and have AV even if you don't need it, like @Tate recommended, you should realize that while you will be safer from viruses (again, low probability, but still exists), this is not free, there are costs involved:

Using AV on the server can add risk to the server, since you're adding potentially vulnerable code - less code, less attack surface. (There have even been cases of attacks on the server via the AV interfaces).
Checking for viruses right there on your server isn't necessarily the safest option, since these can potentially "leak" and fool the AV. (Also see George Ou over on ZDnet about defusing a bomb in your living room).
Of course, never forget the performance costs of running AV on your servers, consider this an opportunity cost. Also you'd need to add X more servers to offer the same performance and throughput, if you have specific usage targets this can cost real money.
Most server-ready AV have a non-negligable cost - more opportunity lost, and if you're spending security money there are better things to spend it on.

All that said, if/when you do decide to go for AV, consider the following points, including the obvious:

Coverage
Cost
Updates
reputation (i.e. do they actively research? what are their triggers? do they catch what they should? etc)
Performance (or more accurately, performance hit - on memory AND CPU, and throughput)
additional engines, e.g. anti-malware, loggers, anti-rootkit, etc
Security of the product itself! You don't want to introduce vulnerabilities any more than you have to...
VERY preferable - if you can offload the AV scanning to another box, e.g. appliance or gateway, so this isnt even ON the server. Or, there are (were?) some products that let you scan in memory, via an API call, without even writing to disk (or DB).


I would recommend reading "Gray Hat Hacking"  by Harper et al. (3rd ed.)

But more importantly, I would recommend doing exercises rather than reading about them.  Perhaps start at overthewire.org and do vortex there.  The exercises cover all of your areas of interest and they contain links to a lot of on-line reading.


Offline brute-forcing of a bank card PIN

The chip embedded in the smart card locks itself after a defined number of incorrect PIN entries, typically between 3 and 10 attempts.


What is the purpose of "g" -> generator of the multiplicative group

SRP is one of the large collection of algorithms which operate in a cyclic group. A cyclic group consists in elements 1, g, g2_, g3_,... up to some value gr-1 where r is the group order (the smallest non-zero integer such that gr = 1). So g is "static" because it actually is part of the definition of the playground: SRP operates in the cyclic group generated by a given value g, using multiplication modulo a given prime N as group law. Note that both client and server must agree on g and N, and the same g and N must be used for a given user. It is easier for the server if the same g and N, i.e. the same cyclic group, are used for all users; and sharing the same group is not a problem for security.

For cryptographic purposes, we need a group such that discrete logarithm is hard, but computations are easy (these two conditions imply that we need a cyclic group, but just not any cyclic group). This requires that N is big enough, and also that r (the order of g) is such that it is a multiple of a big enough prime (at least 160 bits). SRP recommends that N be chosen as a "safe prime", i.e. N = 2q+1 where q is also a prime integer. If N is a safe prime, then the order of any g in the 2..N-2 range is necessarily q or 2q, hence appropriate.

If you choose g = 1, then you get a cyclic group of order 1 and all your values will be 1; any password will be accepted and there is no security at all. Similarly, if you choose g = N-1, then you get a cyclic group of order 2, which is not substantially better.

However, any value between 2 and N-2 will be good for g (if N is a safe prime). Then, we may as well use g = 2, which is optimal for performance (though the gain is slight when compared with a random g).


Is this normal

Yes, FTP/SSH recon and brute force is pretty common. Welcome to the wild wild web.

  or should I take action on it?

You should definitely take action on it. Is there a reason why you have anonymous FTP exposed? This is highly insecure. The files in your case don't exist, but what if an attacker asks legitimate files like your application code or system files like /etc/passwd?

These are the steps you should take to avoid this:

Disable FTP and use SFTP. SFTP uses ssh tunnel and it provides both confidentiality and integrity of data during transit.
Disable anonymous logins. Turn on key based authentication and use strong keys (2048 bits or more). If keys don't work for you, use strong password.
Check the FTP logs to see if any legitimate files have been stolen.

In case you are curious where did they get your IP and why are you seeing this kind of traffic, please refer to my related answer on webmasters:
https://webmasters.stackexchange.com/a/72312/18258


Whonix routes all of the network traffic via Tor, so theoretically speaking - yes. However, there are many other ways in which you can be de-anonymized. Just because you send your traffic over Tor, it doesn't necessarily mean you're 100% anonymous. For example, the actions you take on the hypothetical machine after the exploitation could de-anonymize you.
I would also advise against installing unnecessary things in Whonix since the process of downloading and installing the binaries could de-anonymize you in itself. This recommendation is also outlined in the Whonix documentation.
A better way of doing this would be to use Whonix for your host (so your traffic is networked via Tor), rent a server with XMR, SSH to that server over Tor, install Metasploit on that server and then use that server to launch your exploit. Then wipe the server entirely when you're done and burn any credentials, etc. Of course, this isn't 100% fool proof either. Since the actions you take on the server you're running the exploit from could also de-anonymize you even if you're using Tor and paid for the server in XMR.
As forest mentioned in the comments, it is also important to ensure that if you're going to SSH to an anonymously purchased server, you need to configure your SSH client such that it does not send all of your public keys, as any other public keys you have configured will also be sent to the server, thus potentially leaking your identity.
In such a case that you only need to perform this once, you could opt for using Tails (it also sends all of the traffic via Tor) over Whonix for the duration of the exploitation since it's an amnesic OS. But always ensure you purchase a server to carry out the actual attacks!
There's a lot of useful information about using Whonix correctly & safely in the Whonix documentation, I would highly advise you to read it. There's also some advice on general opsec practices.


Calculating Entropy using md5sum, sha256sum etc

TL;DR: Your formula is too simple.

So the problem is why "" has an entropy if 0 with your formula, but MD5("") has not 0.

As said already in the comments, your formula only works if the data is perfectly random (uniform distribution, all bits independent, etc.).
Example for random case: Your PIN calculation with 4 digits between 0 and 9.
But if you have eg. some value that can either be 2222 or 7777 and nothing else, the entropy is just 1 bit. There are still 4 digits, but most 4-digit numbers are not possible, so your formula doesn't work anymore.

The same is true for your hash - hashing a 0-length string gives exactly one output, always the same. Not 256^16 possibilities that 16-byte hashes can have.

A better formula:

H(X) = sum (-p[i] * log2 p[i])

where p[i] is the probability of the i-th possible value (not digit etc., but value - your PIN has 9999 possible values, and each one has its own probability).

With this formula and the one single possible hash value, you get 0 too.

In general, a hash like this never can increase entropy. It may be the same or less than the one of the original value (less especially if the data is longer than the hash, ie. the hash has less possible values)


From what I could find out about it in a few minutes of googling, Mega-D/Ozdok is a pretty typical smabot: It implements the STMP protocol internally and do handles retries to work around greylisting.

The email address used in the "from" part of the mail depends on the exact template that was sent to the bot. If you look at the fortigate description of the bot, you'll see what options could be used to built it and some samples. It doesn't seem to be using anything from the bot client's machine but it seems to often use the recipient's email in the from field (which means you can protect against these spam using SPF or DKIM).

The bots WILL send their mail through a SMTP server but that will be the recipient's SMTP server: what is referenced in the MX DNS record of their mail domain (or the A record if there is no MX but there is an A).

If you want an analogy to the real world, it's as if, instead of sending (regular) mail to your home through the postal system the spammer hired a lot of strangers to deliver it directly into your home's mail box.

As for whether each spambot has a SMTP server installed, the closer to an answer is: no, there is no SMTP server installed on the client that will accept and relay mail. However, it will accept spam templates from the CC servers as well as "job lists" containing the target email address and then act as a SMTP client to send these mails directly to the recipient's SMTP server.


Does stretching a hash increase a denial-of-service (DoS) risk and does brute-force protection mitigates that?

1) In a sense, yes, since checking the password against a stretched hash will take more CPU time. But you should have some rate-limiting in any case to prevent brute-force guessing passwords, and while doing that, you can take into account the DoS potential. Also, login attempts will not be the only way to (try and) DoS something, you might get excessive load from other requests too, or just receive excessive amounts of network traffic, preventing legitimate requests from reaching you.

I think making it harder to crack the passwords in case of a leaked password database is worth the cost, but of course it is a trade-off. You have to take into account the expected amount of (valid) logins, and that the system can handle them. With millions of users, the stretching might start to take its toll.

2) Yes, if you rate-limit connection attempts and start denying them outright at some point, it would be useless work to run the hash fully for a login that is going to be denied. Though, returning a failure immediately will reveal via timing the fact that the password wasn't even checked.


Is data in iPhone "spare" flash memory also encrypted and shredded?

First I'd like to ask is flash memory used in an iPhone?

Yes.

  When you reset an iPhone the memory gets encrypted and the keys are deleted. But is the data in the worn out area also encrypted…?

Data in an iPhone's flash memory is always encrypted. When the phone is reset -- either through a software restore, or using the "Erase all content and settings" option in Settings -- the encryption keys are overwritten. This makes it impossible to decrypt any of the old data, whether it was stored in an active part of flash memory or not.

Apple's white paper iOS Security explains the device's hardware security in more detail. It's worth reading.


From a technical and theoretical stand point there is nothing that prevents you from applying ESP after AH in transport mode. The proto field is restored again when ESP is removed. So unless other parts of the IP header that AH protected were modified on the way (e.g. the source IP due to a NAT) this should work fine.

But since AH is used to protect the integrity of the transmitted data you usually want to do that last. And if you use ESP with both encryption and authentication you'd do that work twice. Therefore, RFC 2401 contained the following text (it's not part of RFC 4301 anymore because the SA bundle requirement was removed):

  For transport mode SAs, only one ordering of security protocols seems
     appropriate.  AH is applied to both the upper layer protocols and
     (parts of) the IP header.  Thus if AH is used in a transport mode, in
     conjunction with ESP, AH SHOULD appear as the first header after IP,
     prior to the appearance of ESP.  In that context, AH is applied to
     the ciphertext output of ESP.  In contrast, for tunnel mode SAs, one
     can imagine uses for various orderings of AH and ESP.

Also, doing authentication before encryption (i.e. if you use AH in confidentiality-only ESP) might not provide the same protection as doing it the other way around.  As RFC 4303 puts it in its introduction:

  Using encryption without a
     strong integrity mechanism on top of it (either in ESP or separately
     via AH) may render the confidentiality service insecure against some
     forms of active attacks.  Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against  active attackers [Kra01].

Where [Kra01] refers to the paper "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)" by Hugo Krawczyk, which argues that under certain circumstances an active attacker might be able to break the encryption in the integrity-before-encryption scheme.


Can a kernel exploit compromise an OpenVZ host?

OpenVZ containers do not have their own kernels. In OpenVZ, there is only one kernel for the host OS and all of the containers. Successfully exploiting that kernel from within a container means potential impact to the OpenVZ host and all of its containers. If you want to avoid this vulnerability, you need a real hypervisor that boots in independent kernel for each virtual machine.


How to track down a rogue laptop connected to an un protected ethernet socket in a big organization?

Any managed switch should be able to tell you which ports it has seen a given MAC address on. Identify the IP, ARP on that network, query switches on that segment for the given MAC address.

Prevention beats all, though: How can I restrict access to network data by an unauthorized computer that connects via Ethernet?


How can Facebook verify my face if it should not have one?

Facebook does not need to store the deleted photos. All they need to do is to use the photos you uploaded to extract the biometric details to be able to recognise your face. That data is what they use to verify new photos.

This is all outlined in their privacy and security settings. You can turn the feature  to collect facial biometric data off.


What threat model implies any benefit to drug dealers using candy bar dumb phones for business with iPhones for personal use?

Sounds pretty sensible to me. There are clear security benefits as long as they correctly compartmentalize their usage.

I don't think that the NSA / GCHQ  threat model applies to most dealers. Without any other other inidicators (terrorist email history / known to the authorities / saw them looking dodgy with 3 phones) then there are a huge amount of phones that are co-located legitimately for large portions of the day. Especially in a city with tower blocks, work/personal phones, different networks etc there is a huge noise to signal ratio.

A low/medium level dealer has a threat model of local law only. Compromise can happen via customer or supplier or possibly by observation on the street. Any of the candy bar phones can be disposed of at will. Rotating the number via copying numbers between phone and sim is pretty quick and simple. One phone for customers, another for suppliers and the iPhone for personal.

In case of customer compromise ditch that phone, supplier compromise ditch the other. Caught on the street, ditch both in different places. Keep the personal phone...absence of a phone just encourages the cops to look for the ditched ones and that phone is clean.


Security bounds of TLS client authentication (from browsers)

While your question looks complex I think it boils down to the following setup:

two servers, client does not know which one is the correct one
both require authentication with client certificates

And your question is, if client authenticates against server A: can this server use the successful client authentication to authenticate against server B? The answer is no, because server A does not have the private key of the client, only the proof that the client knows the private key. And since it does not know the private key server A can not proof to B that it knows the key. For details about this process see How does SSL/TLS work? where it states: "CertificateVerify: a digital signature computed by the client over all previous handshake messages.". And because the handshake messages are different between client and B to client and A a simply replay of CertificateVerify is not possible but the private key of the client is necessary to create a new CertificateVerify.

The situation would be different if no client certificates are involved, i.e. only username and passwords. In this case server A would get the credentials and could use them to identify against server B (classical phishing).

The situation would also be different if server A only forwards between the client and server B without modifying the messages. It is not possible for A to sniff or modify data in this case but if server B considers the IP address where it got the client certificate from as trusted for other purposes, this trust could then be used by server A.


Should we rethink our entire password strategy?

I'd dispute that changing passwords regularly is really a "best practice". It is more a "widespread practice" which can be traced to military procedures dating from, at least, the times of Julius Caesar. Applicability to computer systems is, at best, questionable.

Password managers are all fine and dandy, but they are actually at odds with the core principle of passwords: a password is something that fits in the brain of the user. Relying on a password manager is a paradigm shift. To state things simply, you no longer authenticate the human user, you authenticate the user's smartphone. This may be considered as befitting modern times; indeed, it seems that the square technological appendices have fused with their hosts, and many humans can no longer be considered as completely defined, let alone happy, if deprived of their favourite gadget. Yet this is a shift that we shall be aware of, and which requires some thorough thinking.

From a pure security point of view, the password manager implies an extension of the user's responsibilities: with a password, the user must keep the password secret and not write it down or reveal it; with a password manager, the user must maintain the integrity of the password manager hosting system as well. In many cases, this does not change much (if the user's machine is infected, a keylogger will grab all the data anyway), but the shift is not completely negligible either. This can be seen from a usability point of view: a password-in-brain naturally travels with the user; a password manager implies a dependency with some software and synchronization procedures.

Besides, as @schroeder explains, recommending an actual product is a delicate matter; this would look like an endorsement, and it complicate things when the product disappears, either through lack of support, or more spectacularly like TrueCrypt.


What are the difference between WPA2-PSK and WPA2-EAP-PSK?

WPA2 EAP-PSK uses WPA2-Enterprise to do an 802.1X authentication to server.  It uses the PSK method of EAP and allows a client to authenticate with just the use of a PSK.

The pros of WPA2-PSK is that it is supported in every 802.11 device of relatively recent manufacture (2nd gen 802.11g or so).  It is simple to set up and simple to use.

WPA2 EAP-PSK should be somewhat more secure in that it would be harder to calculate the PSK from captured traffic.  However, many of the same vulnerabilities exist if an attacker were able to get a hold of the PSK (social engineering, written down, etc).

There are a number of drawbacks:

Like other WPA2-Enterprise methods, you need to have an authentication server set up to authenticate against which adds complexity.
Both the server and the client supplicant need to support the EAP method.  AFAIK, only wpa_supplicant has support for EAP-PSK and you will not find this native on most devices.
EAP-PSK has never passed the "experimental" stage of development.
There doesn't seem to be a lot of interest in it, either people don't want the complexity of WPA2-Enterprise at all (even with a simple authentication method) or they are content to use other more widely supported EAP methods.


Writing errors to Apache's log file from PHP - are there any pitfalls?

Yes.  This data should be useful to help debug errors, however, there are at least a few (maybe more) potential security pitfalls to consider:

Is any of the data privacy sensitive (like social security numbers, passwords, addresses, etc...?)  If so, there could be privacy concerns, but those most of those concerns should already exist with the website anyway.
Logging passwords would be exceptionally dangerous as it would be a plain-text storing of the user's password, which is very bad.  If an attacker would be able to open the log file, he could look then look at all passwords entered!  On this point, an administrator could also look at the user's password, which is not supposed to happen (because the administrator could then impersonate the user), so I would highly recommend not logging the content of passwords.
Are the files adequately protected?  They should only be accessible by administrators.  The system needs to be patched consistently to deter potential attackers from elevating their privilege to root to read the data.


Is there anyway at all people on my wifi could see I use TOR?

Assuming a family member is technically savvy enough, yes, they could probably tell you are using TOR.  The easiest way to do this would be to sniff the outbound packets on the network and analyze them using the TOR dissector in Wireshark. TOR packets are easily identified, as are TOR entry nodes.


How to encrypt data in frontend/backend with a key that is not stored anywhere and is only known to owner?

Upon initial user registration, generate a strong encryption key using a cryptographically secure pseudorandom number generator; this key will serve as the Data Encryption Key (DEK) to encrypt the user's data. But you don't want to store the DEK anywhere, at least in its plaintext form. You want to derive an encryption key from the user's password, using a key derivation function such as PBKDF2. Use the key that you derived from the user's password (the Key Encryption Key, or KEK) to encrypt the DEK. Then you can safely store the ciphertext of that DEK in the database.

Each time the user subsequently logs in, you must not only authenticate them but also derive the KEK all over again from their password, then use that derived key to decrypt the ciphertext of the DEK. Store the DEK in the session on the server, not in the client. Now you're in business; you can use the DEK to decrypt information on the server side for as long as the session is active, but not after the session expires.  This has the advantage that the user doesn't have to stare at some gobbledegook ciphertext. You can instead have a placeholder container DOM element saying "encrypted" or something, and maybe listen for clicks on that element, which then invoke a call to an API endpoint, which grabs ciphertext from the database, decrypts it on the server with the DEK that you stored in the session, then returns it to the client as plaintext right then-and-there, where you can inject it into the UI for the user to see. No sensitive data need be stored on the client, nor is it necessary to perform any cryptographic operations on the client. This approach also has the added benefit that the DEK can stay constant over time. If the user ever changes his password, just derive a KEK from the new password, and re-encrypt the same DEK as before with the new KEK, and store the new ciphertext of the DEK in the database as before.


Code signing certificate for embedded application

Suppose a CA will issue such a certificate for the code , does the public key which is signing the certificate will be attached to it ?

Not directly. However, it is easily to obtain the issuer's public key by building the certificate chain, which will include all certificates in the certification path and their public keys. Normally, you don't have to write your own code for that, just use any suitable crypto framework to retrieve issuer certificate and validate the code signing certificate.

For Windows platform you should use Windows CryptoAPI, for *nix you may use OpenSSL.

  Do I have to parse the certificate inside the embedded application ?

again, not directly. Use suitable crypto frameworks and delegate them all certificate validation tasks. They will ensure if presented certificate and its chain is valid and not tampered.

  Where can I get an example of such a certificate ?

for productional environments it is preferred to purchase code signing cert from a globally trusted commercial CA.

For private scenarios you can use enterprise private PKI to obtain such certificate. Contact your systems administrator for more details.


A popular crypto library is libsodium, based on NaCl, which provides an easy way to perform basic cryptographic operations like key exchange. It supports few algorithms, but the ones it does support are modern, secure, and chosen to work in a wide-variety of situations, removing the necessity to be understand the details of various crypto primitives. The library is for C, but it has been ported (usually in the form of C bindings) to many different languages, including to Node.js.

Installing it for Node.js is simple:

npm install libsodium


Can I use a normal wifi adapter instead of a alfa card for evil twin attack?

The external Alfa wifi adapters are recommended because they use wi-fi chipsets that support all the necessary operations (e.g. packet injection and monitor mode) that are required for full use of the aircrack-ng suite, and the latest Kali distros support them out of the box without much faffing around.

This reply explains it more fully.


Multibyte Character Exploits JSP/PostgreSQL

Multibyte based SQL Injection is only an issue if mysql's encoding has  been set to GBK.  Your client and all of your tables should probably be in UTF-8 for compatibility or Latin1(seems to be the default in the USA). Multibyte character exploits are not a problem with these two encoding types.


It's not that easy...
Example 1
Let's take SQL Injections as an example. You see a site like example.com/?page=1 and you try to change it to example.com/?page=1'. Suddenly you get an SQL error printed.
Is this a hacking method or an individual exploit?
Example 2
Take a local kiosk system with an attached keyboard. By pressing Win+R, I was able to start a command line and add a new local user.
Is this a hacking method or an individual exploit?
Example 3
ImageMagick is a popular image manipulation tool, with many bindings to popular platforms. It had a vulnerability which allowed me to upload files in mvg and svg format, which contained special schemas that allowed me to read and modify local files of the server.
Is this a hacking method or an individual exploit?
Methods versus Exploits
As I was hopefully able to demonstrate, it is difficult to judge what is considered a method and what is considered an individual exploit. Quite often, a "method" is just a very widespread vulnerability, such as insufficient output encoding, leading to all sorts of injection attacks.
It can also happen that potentially exploitable vulnerabilities are forgotten, such as it was the case with scriptless attacks. The paper is from 2012, yet I recall mentions of CSS-based keyloggers as early as 20051.
If you are interested in learning about various exploit techniques, I recommend looking at real exploits, such as posted on Exploit-DB and try to understand how they work. If you come across a specific exploit and don't understand it in detail, I'm sure a well-written question here will give you high-quality answers. Sadly, there is no way to just look up a bunch of techniques Wikipedia-style and suddenly become üb3r1337 - similar to how you can't read a bunch of programming paradigms and become a rockstar developer.

1Although please don't quote me on that exact date.


malware stream my phone activities to attacker

1) Unless you know very well what you're doing (for example experience with malware reverse engineering) or you know the exact malware used, I would advise against this. I would say it's better to just format the phone outright.

2) How do you know that there is malware on your phone? This would help track down where you might want to look.

3) This website talks about recording Bluetooth packets. This uses the phone's storage so it may be compromised by the malware, but I have personally not found malware that modifies these logs. According to http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm the way to get the logs of Bluetooth packets is as follows:

On the Android device go to Settings.
Select Developer options.
Click to enable Bluetooth HCI snoop logging.
Return to the Settings screen and select Developer options.
In the Developer options screen select Enable Bluetooth HCI snoop log. The log file is now enabled.
On the Android device turn off Bluetooth.
Turn on Bluetooth.
Reboot the Android device.
The HCI log file is now being generated and is saved to /sdcard/btsnoop_hci.log.

As for recording communication over WiFi, I would recommend connecting to the AP and running WireShark on your computer to see what packets are flowing between your phone and the AP.


Practical ways to prevent Denial Of Service attacks

IP spoofing is forging a new IP datagram impersonating a different machine from your own.  This is done by modifying the IP header, replacing the source address (your own) with a forged one.  This is successfull because IP is a stateless protocol and (in addition) provides no type of integrity on its own.

Any type of integrity control would prevent it such as TCP-AO or IPsec-AH.

TCP-AO (TCP authentication option) provides a MAC calculated over the TCP packet and some sections of the IP header (such as addresses).  A MAC algorithm provides message authentication, meaning this that we can detect if these fields have been modified in transit.

IPsec-AH calculates a MAC on the whole IP header and on the IP payload.  This MAC allows us to detect whether the whole IP datagram has been modified in transit.

SYN cookies have nothing to do with IP Spoofing.  SYN cookies are used to prevent DOS attacks.
Port knocking is really focused on avoiding your machine ports to be scanned.


Are The ca Policy Values In the OpenSSL Configuration File Applied When Both Creating AND Signing Certificates?

If I used the 'ca' command to generate a Certificate Signing Request ("CSR"), and no values were supplied for the "optional" policy fields, ...

Mu. THIS IS IMPOSSIBLE. The openssl ca command cannot generate a CSR, and never does. It does do several things, resulting in a quite long man page describing all the things it does, none of which is generating a CSR. Since it doesn't generate any CSR ever, it is meaningless to talk about the contents of something that doesn't exist.
The command that normally does generate a CSR is openssl req with the -new option (or -newkey which implies -new). The req command also uses configuration, but it uses different configuration than the ca command. In particular it does not, ever, use any policy section in the config file, so the contents of any policy section in any config file never matter to req. However, the attributes that req can (or does) put in the Subject DN are configured using a config section designated by the distinguished_name item, and in the 'standard' (upstream) config this section is [req_distinguished_name]. This is described on the man page for req, which is a different man page than for ca because it is a different command.
(For completeness, openssl can also generate a basic/trivial CSR from an existing certificate with openssl x509 -x509toreq. This is rarely useful.)

Now let's use the 'ca' command to sign an existing CSR. Using the values contained in the same [ policy_basic ] policy section, are the following CSR Subject Name RDN values required to be present in the CSR before the CA certificate will be allowed to sign the CSR: ...

Almost. Issuing a certificate is NOT signing the (or any) CSR. As I said on at least one of your previous Qs, if you look at a CSR and the resulting cert you can see the cert is different from the CSR. The openssl ca command, like any other ('real') CA, creates a cert partly using data from the CSR, and signs that new cert NOT the CSR.
With that corrected, yes fields (technically attributes but Eric wasn't strict about terminology) designated 'match' in the policy section in the config file must be in the CSR with the same value as the CA's (parent) cert, and as result the value in the new cert will be the same as both the CSR and the parent cert.
The order may be different: as described on the man page, openssl ca in the absence of -preserveDN or config preserve will construct the new cert Subject DN in the order specified by the policy config, regardless of the order in either the CSR or the parent cert. It is conventional to order the RDNs in X.509 DNs from 'large' to 'small' (Country, STate, Locality, Org, OrgUnit, CommonName) so commonly the order in policy and CSR will already be the same, but OpenSSL doesn't require this. Also you should be aware that while actual, encoded DNs are as I said usually 'large' to 'small', some programs and libraries follow the LDAP convention of displaying (and if applicable entering) them from 'small' to 'large' i.e. in reverse order; if you aren't aware of the convention this can be confusing.


Does it matter if a brute force search for a password returns a collision and not the password?

Steffen's answer covers this perfectly, but I just wanted to add a few more details.
Anything that gives a match is usually fine
As he says, you generally don't care about finding the actual password, because many applications will be happy to authenticate you with any string that happens to hash to the hash value stored in the database.  This is most often true for web applications, but may be less often the case in other contexts.  This means that if you perform a brute force search and find something with the same hash, you can login to the account even if it isn't actually the same password.  This, as implied in the question, is the nature of hashing and is a direct result of the pigeonhole principle.
Until you need the actual password
However, there may be some cases where you do want to find the original password.  This would be the case if for instance a hacker stole a username/password from a valueless service and wanted to try to login as the user on a more valuable service (Facebook, banks, etc...).  Since people often use the same password everywhere, then in this case you really do want the original password - not just something that hashes to the same value for a given hashing algorithm (after all, different services may use different hashing methods, and most also use cryptographic salts - h/t @Taemyr).
But the difference doesn't matter
Fortunately (for our attacker), this doesn't really matter.  The reason is because an exhaustive brute force is effectively impossible.  Instead a hacker will try things that are likely to be passwords (word lists, common passwords, etc...).  As a counter example imagine that despite the impossibility of it you have a hash from a web service and manage to perform a brute force search on all possible 256 bit ASCII strings.  You find three inputs that hash to the same value as the user's password hash:

BD3EDF42F6D3AF2DAAE93313EB534
7AF7B8B8F84443872C48EC372DBD1
password

Which would you guess is the actual password?  The answer is clearly #3.  I mean, there is technically a chance that the user just happened to pick an extremely strong password (i.e. BD3EDF42F6D3AF2DAAE93313EB534) that just happened to hash to the same value as password, but the odds of that are effectively zero.
In this sense the attacker has a nice advantage.  They would prefer to find the actual password, and it turns out that because people are bad at picking random passwords, the best way to do that isn't by checking everything anyway - it's by checking things that look like passwords.  This makes brute forcing searching much, much, much, much more effective, and also gives the attacker a much more useful result (the actual password, rather than some random string that happens to have the same hash).


Whether certificates can be used for regulating access

A certificate typically implies that you have taken a public key and gotten a certificate authority to sign it to validate identity.  You don't need this second step; you just need a list of the public keys you are willing to accept from trusted users.  E.g., in ssh you have a list of trusted public keys that you put in your ~/.ssh/authorized_keys allowing people with the associated private keys to ssh into the machine.

Obviously, you may need a signed SSL certificate for your server, so users can verify your identity.


SMTP with STARTTLS itself is not a vulnerability, though it offers a larger attack surface given the complexity of the typical TLS implementation. If you don't need it, turn it off (NIST SP800-123 §4.2.1 PDF).

If you're relying on SMTP+STARTTLS alone for communications confidentially, it's easy to get it wrong.

STARTTLS protocols (LDAP, FTP more or less, POP3 & IMAP, even HTTP which Apache supports, though it never caught on) are inherently trickier to manage from security policy and firewall perspectives. For example if you have a rule permitting HTTPS to a correctly configured web server, all a firewall need do is verify/enforce SSL/TLS records.

With STARTTLS protocols, to ensure encryption with a similar level of confidence you must have either greater protocol inspection (may not be available on your firewall, may require a proxy); or a far greater faith in the client and server implementations (e.g. to prevent sending or accepting plain text credentials).

The above point is more or less what the warning was about: with a strict TLS protocol like HTTPS you can be more confident (NULL ciphers aside) in the connection encryption than with STARTTLS and the possibly optional negotiation of encryption. It is a risk that needs to be evaluated, not a vulnerability.

The typical (non-client auth) SMTP+STARTTLS configuration (from my experience) is:

opportunistic STARTTLS
fall back to clear text on error, or when STARTTLS missing
has poor defaults (cipher selection, certificate validation)

To properly use STARTTLS to increase communication security you have to consider DNS, the elphant in the room, MX backups and MX override ("mailertable").

A client-auth (SMTPAUTH) server with STARTTLS is easier to secure if it's just to enable roaming client authenticate securely (via client certificate, username/password, or both) for relaying purposes.

An ideal secure channel implementation offers (at least) three things:

confidentiality/privacy (encryption)
authenticity (proof of identity of one or both parties)
integrity (tamper-proof, or tamper-evident)

SMTP+STARTTLS deviates from this:

since the communication starts over, and relies on, an unauthenticated, corruptable  plain text channel, there is scope for MITM interference. If STARTTLS is opportunistic, this means it could be trivially subverted (if you've ever seen a Cisco PIX or ASA doing its SMTP protocol "fixups" you'll have seen something similar in action). Similar problem if certificate validation is lax.
SMTP is a store-and-forward protocol, the TLS capability is only point to point, there is no HTTP proxy-like "CONNECT" feature. i.e. this is not end-to-end encryption. Confidentiality, authentication and integrity are limited to the connection(s), not the message, which might not be what a user expects or requires. See also How can a non-technical user verify a message was sent "securely"? ...or over TLS?


Should user account be locked after X amount of failed logins?

Account lockouts on remote applications (e.g. where the attacker can't reset the number of attempts without further work) are mostly to prevent easy brute force attacks against accounts. If you have users who select very weak or common passwords, and your system doesn't make any attempts to prevent the use of these, it's entirely possible that an attacker would be able to gain access to some accounts, even with account lockout implemented. However, that doesn't mean that it's not worth implementing - for users who select slightly better passwords, it massively slows an attacker, and may alert you or your users to potential attacks.

This is different to choosing a password storage method, which is generally attempting to defend against attackers who have obtained your user database. Obviously, in that case, you can't stop someone from making as many attempts to guess the password as they like - they can simply hash a bunch of passwords with the salt from your DB and compare until they find a password which gives the same hash.

However, the specific method which you're using to log the failed attempts is a problem. You're logging the username and incorrect password. In most cases, the likelihood of a legitimate user mistyping their password is higher than that of an attacker trying to log into the system. In that case, the log table you're keeping becomes valuable to attackers - it contains usernames with strings which are likely to be close to valid passwords for the accounts. If users have passwords just for your site, this could massively decrease the effort required to brute force passwords if your DB was accessed, and if the users have accounts on other systems with the same passwords, even if the other systems use account lockout schemes, you've just given attackers a much better chance of guessing the correct password within the attempt limit.

You don't need to store the password. You only care about the number of attempts against each account. That could be an integer value linked to the loginid, and would be sufficient for your lockout process. You can separately store the source IP, and monitor for unusual traffic patterns, although you do risk blocking legitimate users who are connecting to your site via NAT-ed connections - mobile providers often group large numbers of users so they appear to be coming from a single IP address, for example.

One common pattern for account lockout is to monitor the number of failed attempts against an account, then to apply incrementing time blocks against that account. For example, after 3 failed attempts, you could block further attempts for 5 minutes. If another 3 failed attempts occur, block the account for 10 minutes, and so on - this can reset once a legitimate login occurs. It can also be useful to show the number of failed attempts to users upon login - if they spot something strange, they can potentially alert you to a problem.

One subtle thing to be aware of with implementing account lockout schemes is that they can act as a username oracle, if implemented poorly. In this case, it is possible to spot distinct behaviour between valid accounts and non-existent accounts, letting an attacker know that a given username is valid. To prevent this, you can either monitor all supplied usernames, and show the same behaviour for non-existent ones as for valid ones, or simply not display when an account is locked. If you choose this, you may cause confusion to users, who may not be able to log in if they're subject to an attack without their knowledge.


Have a look at Major Malfunction's (Adam Laurie) work in this area:

http://hackaday.com/2007/03/25/rfidiot-rfid-io-tools/

http://www.youtube.com/watch?v=3vAvesYoHeo

and many others - good fun stuff, not too expensive to get started

edit: Just spotted this post on Proxclone that you might also be interested in


How do you prevent physical backups from being stolen?

On-site storage

Fireproof safe/cabinet in a access controlled environment is often considered safe enough, It is manual labor to actually put the drives/tapes into the container. Example:
Attached fireproof media container. An example here is SentrySafe. A cheaper example is ioSafe.
Site redundancy. When you already have site redundancy for your applications you may also have the backup redundant on both sites. This can be a cheap solutions if you already have site redundancy for your solutions. (Example: A site which is reachable, but site is both in UK and US. Often solved through global load balancing).

The not so obvious solutions for physical security:

Each storage device should be marked with unique identifier. This should be stored for bookkeeping. Bar codes can be a good solutions for easy scanning devices in and out.
Keep inventory of all backup devices.
Access control on access to storage room.
Keep records of who has access and who invokes access for what times. Keep in mind seperation of duties is important.

Off-site storage

Vaulting - You let someone else store your drives/tapes. Banks and security firms can often provide this type of service. They will however most likely store it just like they store other valuables.
Electronic storage - You copy the data to the other party who stores your backup. A simple example is Dropbox or Google Drive.

Storing off-site will most likely increase the expenses, but will help you a great deal in case of anything happening to the on-site property. This can often be considered as a last line of defense.

During transit

Drive Carrying Case, A Hard-shelled Waterproof Case - From Amazon

Backup media rotation

One should adopt a good backup strategy (like grandfather, father, son system). Once a system like this is in place it is recommended to rotate the use of hard-drives and tapes so you can easily identify how much the media device has been used. This is so you can easier calculate when to replace disks or tapes when their life expectancy has worn out.


How is user authentication sent in a public wifi? Radius/802.1x/EAP etc

Everything is authenticated based upon the mac address of your wireless card.  When you connect initially you are assigned a DHCP address by the gateway device which is controlling your DNS.  Before you are authenticated all DNS requests are redirected to the HTTP(S) server of the gateway device. This controller has created you an account based upon your mac address and once the payment authorization is received it enables your account to access the public DNS server for full access to the internet.


Is end to end email encryption possible without unique domain/subdomain for each user?

Unless you're doing end-to-end encryption (where the servers only see encrypted messages, other than the recipient's name), there's no real security, so having something like this in the mail submission or transport protocols isn't going to be useful.

The receiving server could certainly encrypt incoming (unencrypted) messages with the recipient's public key, then securely erase the unencrypted message and transient key, which would make it somewhat more secure, but you still have to trust all intermediate servers.  You can't even force them to use a secure transport from server to server!

Even if there was an extension to the mail transport protocol for the receiving server to send a public key of the recipient, you're still trusting that the receiving server is sending the correct key.  It could easily send a false key, decrypt and save it, then re-encrypt with the correct key.  If you CAN trust the server, you might as well have it just get the unencrypted message (using secure transport) and encrypt the  message itself.

Having an e-mail client with built in support for encryption and authentication/key management is really the only secure way of doing it.  There's no reason you should have to trust the mail servers.


Assuring Client is Authorized to use JSON Web Token

In one sentence: you have to trust the client to use TLS and generally protect the token.

Like many token systems, JWT relies on the client to secure its token. Clients are already required to maintain credentials needed for authentication (eg: passwords) so this is not a radically different concept. Furthermore, JWTs typically have a much shorter expiration time than credentials so securing them is typically easier.

Below are some snippets from relevant specs.

The JWT RFC, which utilizes the JSON Web Signature RFC, requires the use of TLS:

  To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

JWTs are similar to the OAuth 2.0 concept of bearer tokens. The bearer token RFC states:

  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

In section 5.2 it goes on to say that TLS must be used to ensurer security of the token in transit, both when obtaining the token and when using it:

  This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection.


Internal network address contains my name - problematic?

What's your IP address?  If it's an RFC 1918 address like 10.*, then you're being NATted to the Internet, and as a comorbid condition* your reverse DNS won't be visible to external sites.  It will still allow the University to track you better internally, which is perhaps why they do it.

If it's not an RFC 1918 address, your DNS name likely does show up externally; you can check with a site like WhatIsMyIP (Reverse DNS Lookup).

*Having an RFC 1918 address implies that your reverse DNS won't be publicized on the Internet, because an RFC 1918 address must be translated (NAT, or Network Address Translation) before going out to the Internet.  In almost all cases, NAT is one-to-many (one public address, many private addresses) or pool-to-many (some public addresses, many private addresses) so there is no one-to-one mapping between the internal RFC 1918 address and the external address the Internet sees traffic from.  If you have hundreds or thousands of students being NATted to one or more public IP addresses, having that smaller number of public IP addresses be mapped to hundreds or thousands of names becomes meaningless.  All of which I glibly summarized as "NAT means no external reverse DNS" above.


You need to blow away the site and start from scratch. They have gained access to your server and changed files. You have no idea how far they have gone, which means "it is not your computer any more". It is very possible that they have replaced various files, which will make it possible from them to maintain access even if you change passwords.

Take down the site, re-install whatever binaries you use, then re-upload your files from a known-good source. Anything less is no guarantee that you can keep them from using a backdoor.

Your code also needs to be reviewed for vulnerabilities by someone qualified to do so. Yes, the comment and email fields are a way for attackers to gain access to your server if those fields are not properly coded.


Assuming the router is set up correctly ALL traffic would go through the first VPN on the router and then it would use your software and create a 2nd VPN connection.
no vpn connection should be ignored.

obviously though it depends on the network set up.


Running webserver with SSL enabled but not used

It depends on the exact vulnerabilities which have been found, but unless there are very specific threats like buffer overflow, code injection, etc. which have been found, the general answer is that if you do not use SSL, then you are not concerned by SSL weaknesses.

SSL goal is to provide communication channel security through confidentiality, integrity and authentication. Generally, SSL threats will try to attack at least one of these points in order to lessen the SSL connection security. This would allow things as deciphering encrypted exchanges, impersonating the SSL server, etc..

But, since you are using HTTP only, then there is no communication channel security used and therefore none to be attacked. So, would SSL port being badly configured with poor cipher suites and poor certificates, this will not affect your HTTP-only service.


Sharing Derived Unique Key Per Transaction (DUKPT) Base Derivation Key (BDK) with a partner

If B specifically wants the data encrypted end-to-end from the field device to them, then indeed you need devices injected under a BDK known to B -- either you generated and gave to B, or B generated itself and gave to you or your vendor(s)/injection facility(s) -- and preferably not used by or shared with anybody else.

You don't say what type(s) of devices and users/settings you are concerned with. I have seen (in the US) some retail/point-of-sale (magstripe "swipe" and pinpad, sometimes EMV) devices that can be injected with two device keys, under two different BDKs. But the ones I saw tended to be the higher end (thus more expensive), and you still have the problem of choosing which key to use for a given transaction/data-item, which usually means some other system that is interfacing with the human(s) involved, like a cash register/till, being modified to make this decision and command the device.

If B is only concerned about the data being encrypted all the time so it isn't vulnerable to attacks, they might well be satisified to treat your server as a single (unusually busy) device in their network -- i.e. they assign you an initial key (and corresponding initial KSN) under their BDK; you get each transaction encrypted by the device under a BDK-A key, decrypt it and immediately re-encrypt it under the BDK-B key, and send it up to B.

If you are using an HSM for your crypto, and for large volumes of payment-sensitive data you should, this is often provided as a single operation called "translate" -- that is, instead of "decrypt under key #3" then "encrypt under key #17", your software can request "translate from key #3 to key #17", and then the plaintext is never visible in your CPU/memory/swap, only within the dedicated and hardware-protected HSM.

Depending on your transaction volumes this could burn through the somewhat-less-than-2^21 values of TCTR pretty fast, so B may have to send you another "device" key (or maybe several) every month, or week or whatever, using some mechanism that is both secure and as automated as possible to avoid mistakes. You should definitely try to have each new key ready at least a week before you expect to need it, preferably more, in case volume spikes or some fault forces you to switch early. But if they're making money on the transactions you send them, and they presumably wouldn't accept your business otherwise, they should be able to manage.


It is probable that some malware included a copy of this HTTP server, or some code which looks like this HTTP server, in order to, say, run a HTTP server on the infected machine. Being able to host parasitic servers on infected hosts is one of the goals of malware, and a lightweight HTTP server code (both in code size and RAM footprint) would be more appropriate for that than a heavyweight Apache or IIS, which would be much harder to smuggle in an email Trojan.

Now of course you cannot really know whether any given piece of software is malicious or not. In fact it is not fully defined: if a server code has a remotely exploitable bug, then it could be used a backdoor for attackers. Whether this bug is malicious or not depends on the intent of the software writer: was he aware of the bug ? It won't change a bit in the code, though.

With opensource software you could try to run your own audit of the code, which will be hard work and does not guarantee that all holes will be found (otherwise, we would know how to produce code without bugs), but that's better than nothing.


Hijacking stale DNS entry to point to your own website

This is a subdomain takeover.
They typically happen in one of 2 ways:

You have an A record pointing to an IP address that no longer exists and an attacker can gain control of the IP address in question
You have a CNAME record pointing to a domain that no longer exists, and the attacker can register the domain.

The reasons can vary depending on the circumstances. To pick two:

Impersonation is much easier if you can control an "official" domain. This can lead to phising, social engineering attacks, and more.
If the main domain has cookies which are valid for sub domains, then the attacker will be able to steal all cookies from the main site if a victim visits their subdomain.

And yes, there are ways to scan for such misconfigurations and attackers can and will find them.
Solution:
The simplest and most effective way to stop subdomain takeovers is to always cleanup you DNS records - don't leave an A or CNAME record pointing to non-existent resources/domains.
In your case though you have another option. You can reserve an elastic IP address to your account and attach/detach it from your EC2 instance as needed. By reserving the IP you will make sure it does not return to AWS' pool for someone else to use. This solution has a slight advantage that you don't have to update DNS or worry about DNS propagation, but it has a slight disadvantage in that you will pay a nominal hourly fee while the IP address is not in use.


How was I able to login Whatsapp Web when my Phone was turned off and SIM card removed?

You say WhatsApp web lost signal with the phone, which suggests it still requires the phone to mirror its connection.  Might the repair shop have connected the phone to WiFi?  If the phone is configured to automatically connect to open WiFi, it could connect without setup on the store's part.  I know WhatsApp does not require your SIM card to work, as you can temporarily migrate WhatsApp when traveling and using a new SIM card.
Edit: ran a test where I removed my phones SIM card and connected with WhatsApp web on another device.  I was able to send/receive messages.
Edit2: the phone must be unlocked to allow the WhatsApp connection.  WhatsApp does not need to be running actively (there is a background process on startup).
At a minimum, your phone was unlocked and connected to (open?) WiFi.  It cannot be proven the store was going through your WhatsApp messages, but it is possible they did.


When a password is set, it's immediately hashed with a random salt S1 and stored as H1.

Hashed on the client side? If not, the password must be sent at least once in cleartext.

  The point here is to ensure that the password is never sent in cleartext; the communication channel between the user and server is assumed to be "reasonably" secure,

Why not use encrypted traffic, such as TLS?


Does turning off my modem before leaving home significantly improve security?

Generally speaking, a vulnerable device/network doesn't become less vulnerable if it is turned off some of the time. Or if you have infected devices on the network, this won't make them any less infected.

However, it may reduce the probability of your router or any exposed service from becoming infected any given day. I guess you could also argue that an already infected device will do less damage to others if it is powered off. But really, there are botnets and others constantly scanning the internet for potentially vulnerable devices, so if your device is vulnerable, it's only a matter of time before it is compromised.

Instead, I'd focus on decreasing your attack surface and fixing weaknesses. Make sure your modem/router is up-to-date, and the same for other devices you have exposed to the internet.


ISO 27001 - procedures templates for ISMS at small companies?

Something like this from the ISO27k Forum? I found a whole bunch of paid-for templates too.
As requested. From the linked site:

The FREE ISO27k Toolkit consists of a collection of ISMS-related materials contributed by members of the ISO27k Forum, either individually or through collaborative working groups organized on the Forum.  We are very grateful for their community-spirited generosity in allowing us to share them with you.
The Toolkit is a work-in-progress: further contributions are most welcome, whether to fill-in gaps or provide additional examples of the items listed below.
Please observe the copyright notices and Terms of Use.
IMPORTANT DISCLAIMER: this is generic information donated by various individuals with differing backgrounds, competence and expertise, working for a variety of organizations in various contexts.  The ISO27k Toolkit is provided as a starting point for you to consider, adapt and enhance as necessary to suit your specific situation.  Your information security risks are unique, so it is incumbent on you to assess and treat your risks as you and your management see fit.  Don’t blame us if the ISO27k Toolkit is unsuitable or inadequate for your circumstances: we are simply trying to help!


One way I've seen this setup, which seemed like a reasonable approach was to allow access from a single host to the management LAN and then have anyone need access connect to that device via rdp or ssh and from there on to the management network.

An advantage of this approach is you reduce visibility of the management network in terms of scanning but you're not tied down to accessing from specific hosts as you would be with a multiple nic solution.

Another advantage is that it should allow for easier auditing of what actions are taken on  devices in the management LAN, by auditing activity on the gateway host.

Of course securing that host becomes very important, both in terms of authenticating the admins connecting to it and auditing activity.


Why has my OpenPGP key been duplicated on expiry change?

Why has this happened? Shouldn't the old key just get replaced with the updated one?

In OpenPGP (at lest for version 4 keys), the expiry date in not stored in the key packet itself, but in binding signatures (self signatures) on the keys. Changes to the expiry date (and other attributes) are performed by distributing a never version of the binding signature, which then superseeds the old one.

As key servers only do partial verification of signatures (if any), they keep all versions around and have the OpenPGP clients perform verification (and choose the newest valid binding signature and thus expiry date). Furthermore, it offers a kind of history of the key.

This was also discussed some years ago on the GnuPG mailing list, also linking an example showing the duplicated binding signatures that occured because of changing the expiry date:

sub  1024D/2D16624C 2003-05-13
sig sbind  FFFD5DA0 2003-05-13 __________ __________ []
sig sbind  FFFD5DA0 2003-05-14 __________ 2007-05-13 []
sig sbind  FFFD5DA0 2011-03-06 __________ 2013-05-13 []

OpenPGP clients like GnuPG will usually discard (or hide) the older versions after verifying the binding signatures.

  Can I be sure that my published key will expire on the new correct date that I set?

Yes, OpenPGP clients will follow the newest self signature available, and consider the older ones superseded.


Can a wifi network have WPA encryption, WEP cipher and OPEN authentication?

This is weird to say the least

WPA supports the CCMP and TKIP ciphers
an SSID supports either WEP or WPA/WPA2

So the answer to your question is no, which begs the question : in which conditions did you get the screenshot?


What security requirements should implement a L2L VPN in order to protect one end from the other?

Some security measure I have gathered:

The remote site should have connectivity only to what is needed (internal IP ranges should be restricted).
The remote site should have connectivity only to the ports and services that are needed.
Only authorized remote sites should be able to connect.
There should be an Intrusion Prevention System (IPS) between the remote site and us.
Communications should be encrypted.
Communications should be allowed to initiate only from the remote site to us, not the other way.


Purpose of Decrypting & Scanning HTTPS traffic

what is the purpose of doing this?

The antivirus wouldn't be able to detect a virus/exploit that was delivered through https. Breaking the https connection would allow it to detect and block such threat.

  It's very clear that they are not using any proxy server.

No. There may not be a configured proxy server, but the aforementioned firewall is acting as one, apparently in combination with a Sophos instance (this will be a transparent proxy).

  Does our passwords gets decrypted in an encrypted websites via MITM decryption

Yes. Anything that goes through the MITM connection will be decrypted and then re-encrypted

  or store logs?

You should ask to the person that configured this system performing a MITM

  Is there any way to get around this?

Disable the "Decrypt & scan HTTPS traffic" rule? It may be possible to configure specific destinations that shall not be subject to MITM.

Also, it could be that connecting through a proxy / VPN allowed to bypass this specific security setting. But in this case I don't think it would be appropriate. If you are allowed not to go through this filtering, you should get this rule disabled. If you are not allowed to bypass it, it seems unwise to work around it without authorization.


Is it safe to leave Keepass always opened on a computer?

It is safe if your computer is safe from unauthorized access. This includes malware.

If your computer is not physically safe, then no, anyone can access your Keepass. If your computer has malware on it, it can also access your Keepass if it is left unencrypted.