Yes, the first 6 are an issuer ID

Those middle 9 digits are unguessable in the sense that should you try to brute force them with a payment processor they'll catch you.

If somehow you had a hash of the complete CCN (or an encrypted version and the public key) you should only need a maximum of 10^8 (100,000,000) attempts to figure it out, as Luhn's decreases the complexity by one order of magnitude.

To calculate a 3-digit CVV, the CVV algorithm requires a Primary Account Number (PAN), a 4-digit Expiration Date, a 3-digit Service Code, and a pair of DES keys (CVKs). source


You left out a very important detail:  how you connect to your employer's computer system to do your work.  I believe you are using LogMeIn, but if not, that would change the answers.

If you are only connecting to a remote desktop (using a product like LogMeIn, Microsoft Terminal Services, RDP, VNC, or Citrix), then no, your employer cannot see into your computer.  Based on your description, I believe this to be the case so you should be well insulated from them.  Depending on the remote desktop product, they may or may not have access to your camera and microphone, but usually those are under your control.  (These devices are commonly made available so you can run your company's IM software like Skype.)  If in doubt, leave your camera covered.

The fact that your credit card number was stolen is purely coincidence; the number and extent of retail and hotel data breaches in the past three years is astounding, and fraud has impacted the vast majority of cardholders.  People have either been wrongly charged, or their cards were among those stolen and the bank sent a replacement before the old card expired.

So to list the answers:

No, you're safe.
Yes, but only in a way you would know.  In the US, it would be illegal to audio monitor you without notifying you of the monitoring (although video monitoring may be legal!)  But you should probably check your work contract or employment policy to make sure you haven't agreed to audio monitoring as a condition of employment.
At home, this is not true and your personal browser is not subject to company monitoring.  (The browser on your LogMeIn desktop is subject to monitoring, of course.)  At work, this is partly true; if your coworker's iPhone uses the company WiFi, their WiFi data passes through the company network and is likely subject to logging or monitoring.  The reason I say it's partly true is that the company can monitor all unencrypted traffic, but not the contents of encrypted traffic, such as iMessages.  The logs can reveal that the iPhone set data to a server at Apple that is known to handle iMessages, but they have no way of knowing to whom it was sent or what it contained. But see the cautionary note below: **
No.  If you have a work computer on your home network, the only way they could get to your home computer without your explicit permission would be to hack it, which would violate the Computer Fraud And Abuse Act of 1984.  That's a federal crime.
Most anti-virus software is useless when it comes to commercial spyware that you're thinking of.  But product recommendations are off topic for this site.

If you are not using LogMeIn, and you are connecting to a VPN tunnel at your work, so your personal computer is actually joined to their network, then the answer is different.  They then have access that is not blocked by any firewall in your home; only your Windows Firewall would prevent them from viewing your machine.  Also, in this case, any traffic from your desktop applications to the internet would pass through their network, where it would be subject to inspection and interception.

** If your employer gave you a Trusted Root certificate to install, they will have the ability to view the contents of your secure https connections.  (On the iPhone installing root certificates is done by installing a "profile"; this may be done under the guise of installing some work-provided required "security software", like AirWatch.)  The root certificate would allow them to operate a transparent https proxy (like Blue Coat); these proxies work by dynamically generating certificates that your new root certificate happily authenticates, allowing their proxy to inspect your traffic.  This is normally detectable by viewing the certificate details in your browser; but viewing certificates is not possible on the iPhone version of Safari.

Trusted Root attacks like this can be thwarted if an application performs "certificate pinning", but browsers can't do pinning, and very few apps take this step when connecting to their home servers.


How to mitigate heartbleed like attacks prior to zero day

The main problem with heartbleed was not that unused secret data where still in memory but that the memory contained secret data which were in use. These were data from parallel requests but more important it was the private key of the certificate which was needed to establish the SSL handshakes.

A typical technique used to protect against this kind of attacks is privilege separation. In case of an SSL handshake this could be using a HSM which can encrypt/sign but never makes the key accessible. It could be a process level separation employed for instance by OpenSSH. Or the critical computations could even be issued by another computer system controlled by a different party like done with Cloudflare Keyless SSL.


How to protect an application from attackers with full read-access to the db?

In this scenario, what attack vectors do you see?

If your platform is the browser, then one possible attack might be to modify your javascript code in transit and add in a few lines of code that share the client-generated keys with the bad guys.

This implies a successful MITM attack on the downstream traffic. This may be made possible by design in contexts where there is content filtering going on between you and the client which needs to read encrypted content in order to make filtering decisions. If an attacker attacked the content filtering server instead of your server or the client browser, it's probable he could succesfully pose as your server and modify the javascript that the client sees, and you'd never know it.

You said that neither the browser nor the server are under an attacker's control, but if either was the case, obviously it would be a piece of cake to break the protocol.

Providing the browser with a plugin which can verify signatures on downloaded javascript may make this safer, but I don't know enough about the browser security model to make an informed guess.

  Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

Based on your comment to clarify the design, I'd say no.


General security of offline databases (like SQLite)

What you're asking is a variant of the DRM problem. In extremely generic terms, this is your scenario:

You have a thing which you want your software to do, on the customer's machine, and
You don't want the customer to be able to do that thing without your software.

This is flatly impossible. If it happens on their machine, you cannot control it. All you can control is what "it" is, at least insofar as your design requirements let you.

Let me talk through a couple of common ways to control "it" though:

Storing the data on another machine, like an online database.

This works fine, except that you're still only protecting that database. Any data sent to the client to be viewed can be stolen by malicious software, which can do anything from sniff the incoming network traffic, to capturing the display cable signal.
Decrypting based on something your software can't access alone.

The most common incarnation of this today is the password, but hardware security tokens are increasingly common alternatives. In short, by requiring some separate thing before it can access the data, your software can quite handily prevent anyone from just reverse-engineering the binary to decrypt the data.

Note that you're still susceptible to the people who own the machine watching your process as it runs to steal the decryption keys, or the data itself, out of memory. Your code might not be able to do it entirely alone, but it's still decrypting each byte with no further user input. Hardware security tokens can help address this, but then you need to actually use the decrypted data, so... you see the point. It's an infinite regression.
Minimize the amount of data you can access.

If your broader service stores credit card numbers, addresses, usernames, and favorite colors, and your specific app only ever needs to access the last two, you can put up brick walls in front of the first two. This touches on the CIA triad, but in short, it's easier to protect against disclosure to unauthorized parties if even authorized parties can't access it.

Which one you choose depends on what you're making, what your constraints are, and how much time and money you're willing to spend. If you're planning to sell this to people for real money, even if you probably won't ever handle obviously sensitive data, you should still probably hire a professional to help you design it securely. As you can guess, it's much better to spend a little money now being proactively secure than a lot of money later when your lack of security comes back to bite you.


EVP_Digest{Sign,Verify}* always hash the data before signing/verifying; that's their whole purpose. Less obviously, the older (before 1.0.0 in 2010) EVP_{Sign,Verify}* also do this. Trying to get them to not hash is kind of like going to the restaurant and buying a steak dinner, taking it home, throwing it out, getting some crackers from the cabinet, and eating the crackers; it works, but it's silly.
To sign/verify a pre-digested value the generic routines are EVP_PKEY_{sign,verify}*; see the man pages on your system or on the web here and here (note the description on the sign page is a little clearer that tbs,tbslen are expected to already be the digest).
Alternatively for ECDSA specifically you can call the underlying primitives ECDSA_{sign,verify}* combined with explicit encode/decode (which the EVP level does automatically) normally using i2d/d2i_ECDSA_SIG which are referenced/linked there.
Crossdupe https://stackoverflow.com/questions/57018976/evp-pkey-verify-doesnt-work-when-using-ec-key for the EVP_PKEY_* option.


Why does a spam sms contain a link to an email address?

Once you reply to the email address they will most likely try to phish more information from you, such as bank account number to transfer the money, name, address, card expiracy date, codes and more. This could of course be automated with a script replying to anyone sending email to that address.


A personnal password should only be known by one person. This in the one of the holy rules is security, and not respecting it might cause more harm that help.

That being said, in one key action is only allowed to one single account, an old but still valid usage is that the account owner writes his credentials on a paper, puts it in a sealed enveloppe and deposits the enveloppe in his company safe. That way, if for any reason, the company needs to use the account when the normal user is not available, it is enough to designate a new account owner, give him the enveloppe and ask him to immediately change the password and deposit the new one in an enveloppe in the safe.

Never underestimate the good old physical ways...


Keep original message identity when sending email messages several times

User A cannot prevent B signing and sending any message to C. This includes messages B received from A in the first case. But, A can send the message or a digest of the message to C too when sending it to B so that C receives the message (or the digest) first from A and thus can derive from this fact that A had the message before B (and thus might have created the message). Or, A could use a trusted timestamping service so that he can later proof that he had the message before B. Similar there could be a trusted party which receives a digest of all messages or one could even use a public blockchain or hashchain for this which can be used to check in which order the messages were sent and by whom.

  Is a digital certificate enough?

No, a digital certificate by itself does not help.


Wuala encryption is based on a Cryptree structure.

For descriptions of different technical depths cf. http://wualablog.blogspot.de/2011/05/wualas-encryption-revisited.html?m=1


ECC is less of an encryption algorithm and more of an algorithm construction kit (some pieces not included).

Not all curves are created equal, and key size (both allowable and recommended) are dependent on the curve chosen. See the literature associated with each given curve for details relating for that specific curve.


Can client-side hashing improve after-the-fact security in response to password leaks?

There are no theoretical benefits from hashing client-side and server-side to hashing twice server-side ; unless the connection between the client and server cannot be trusted.

However in practice, I have seen multiple instances where plain-text passwords ended-up in logs (mostly in error logs). In this particular scenario it has a clear advantage.

I believe you hashing from H0 to H1 is feasible with a salt that is unique per password.

Once H1 is compromised, because the server knows this particular Salt, the client could authenticate by sending H0, and then the server can check that H0 + Salt => H1. Then the server could change the Salt to Salt' and register the H0 + Salt' => H1' as the new password.

I think this is possible, but I'd advise against it :
Complexity is the enemy of security.


Verifying the authenticity of a public key without manual intervention?

You are talking about public key infrastructure.  This is why certificate authorities and webs of trust exist.  You have to have some trusted party to verify the certificate (public key).  Verification occurs by signing the certificate using a private key that is trusted by the person the public certificate is going to be shared with.

This can either be a central trusted CA (either a third party or an internal CA for an organization which everyone agrees to trust) or it can be a web of trust where multiple people sign the certificate when they verify the information and trust is established based on how much you trust the people that signed it.  The exact schemes can vary from one web of trust to another, but at the simplest, if I trust Bob and then Bob trusts Carl, I can trust Carl since Carl is signed by Bob and I trust Bob.  Then if Carl trusts Dave, I can trust Dave, but perhaps a little less than I trust Carl or Bob.  There is still the manual action of originally verifying Bob, but I get Carl and Dave for free.


To understand the attack, one must recall Bleichenbacher's attack from the late 20th century. In that attack, the attacker uses the target server as an oracle. When using RSA-based key exchange, the client is supposed to send a secret value (the "pre-master secret") encrypted with the server's public key, using PKCS#1 v1.5 padding (called "type 2"). Bleichenbacher's attack relied on sending carefully crafted values in lieu of a properly encrypted message, and observe the server's reaction. The server might respond (most of the time) with an error saying "I processed that but it did not yield a proper PKCS#1 v1.5 type 2 padding"; but sometimes, the decryption seems to work and the server proceeds with whatever it obtained. The attacker sees that difference in behaviour, and thus gains a tiny bit on information on the private key. After a million connections or so, the attacker knows enough to perform an arbitrary decryption and thus break a previously recorded session.

This attack is of the same kind, but with a new technique that relies on the specificities of SSL 2.0. SSL 2.0 is an old protocol version that has several serious flaws and should not be used. It has been deprecated for more than 15 years. It has been even formally prohibited in 2011. Nevertheless, some people still support SSL 2.0. Even worse, they support it with so-called "export" cipher suites where encryption strength is down to about 40 bits.

So the attack works a bit like this:

The attacker observes an encrypted SSL/TLS session (a modern, robust one, say TLS 1.2) that uses RSA key exchange, and he would like to decrypt it. Not all SSL/TLS sessions are amenable to the attack as described; there is a probability of about 1/1000 that the attack works. So the attacker will need to gather about a thousand encrypted sessions, and will ultimately break through one of them. The authors argue that in a setup which looks like the ones for CRIME and BEAST (hostile Javascript that triggers invisible connections in the background), this collection can be automated.
The server carelessly uses the same RSA private key for a SSL 2.0 system (maybe the same server, maybe another software system that may implement another protocol, e.g. a mail server). The attacker has the possibility to try to talk to that other system.
The attacker begins a SSL 2.0 handshake with that system, using as ClientMasterKey message a value derived from the one that the attacker wants to decrypt. He also asks for using a 40-bit export cipher suite.
The attacker observes the server's response, and brute-forces the 40-bit value that the server came up with when it decrypted the value sent by the attacker. At that point, the attacker knows part of the result of the processing of his crafted value by the server with its private key. This indirectly yields a bit of information on the encrypted message that the attacker is really interested in.
The attacker needs to do steps 3 and 4 about a few thousand times, in order to recover the encrypted pre-master secret from the target session.

For the mathematical details, read the article.

Conditions for application:

The connection must use RSA key exchange. The attack, as described, cannot do much against a connection that uses DHE or ECDHE key exchange (which are recommended anyway for forward secrecy).
The same private key must be used in a system that implements SSL 2.0, accessible to the attacker, and that furthermore accepts to negotiate an "export" cipher suite.Note: If OpenSSL is used and not patched for CVE-2015-3197, even if "export" cipher suites are disabled, a malicious client can still negotiate and complete a handshake with those disabled cipher suites.
The attacker must be able to make a few thousands or so connections to that SSL 2.0 system, and then run a 40-bit brute force for each; the total computing cost is about 250 operations.

It must be well understood that the 250 effort is for each connection that the attacker tries to decrypt. If he wants to, say, read credit card numbers from connections he observes, he will need to make a non-negligible amount of work for each credit card number. While the attack is very serious, it is not really practical in that CCN-grabbing setup.

The solution: don't use SSL 2.0. Dammit. You should have stopped using SSL 2.0 in the previous millenium. When we said "don't use it, it is weak", we really meant it. It is high time to wake up and do your job.

Supporting weak ("export") cipher suites was not a smart move either. Guess what ? Weak crypto is weak.

Deactivating SSL 2.0 is the only right way to fix the issue. While you are at it, deactivate SSL 3.0 as well.

(And that fashion of using all-uppercase acronyms for attacks is really ridiculous.)


Inspecting code elements in browser when logging in

Yes, this is normal.

The networking tab in the Chrome developer tools show network operations for the website you are on, but all this traffic would be encrypted over the wire if the site uses SSL/TLS.

For example, here's a login captured on a website with SSL/TLS:

General
    Request URL: https://www.w3schools.com/action_page.php
    Request Method: POST
    Status Code: 200

Form Data
    uname: someUsername
    psw: somePassword
    remember: on

And if Wireshark is used to capture the post request, all you can see is some encrypted data.


Should 2-factor authentication using SMS be deprecated?

Bruce Schenier talks about this issue here.

To quote the article.

  Here are two new active attacks we're starting to see:

  Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
  Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

  See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The problem with 2fa is that the password and the otp are both sniffed. Or just the password is sniffed and then the user taps the 'tap here to login' prompt. Either one allows the attacker in.

As mentioned by defalt. The proper way to authenticate a user (mathematically speaking) is to use strong mutual authentication like how yubikey's security key does.

  1) What is a foreseeable future - is it going to happen, that worldwide GSM providers will soon fix all the vulnerabilities and upgrade the technologies easily? And if they don't plan this, then what should we do?

Things take a very long time to change because of lock-in . Ipv4 was predicted to be dead by 2010. In 2019 ipv6 usage is about 25%. Rolling codes were created back in the 1980s but fixed code systems are still around in 2019. So sms will stick around for a long time to come.

The best thing you can do is utilize the strongest authentication that a website has available. There's not much an individual user can do beyond that. It's really up to the website to implement strong authentication.

  2) What is a foreseeable future of internet - does GOOGLE, BANKS and all others tend to deprecate SMS authentication soon, or that's not gonna happen, and we are will be still sticked with #1 problem?

Google and Yubico are working hard on upgrading user authentication for the internet in 2 ways. 1. delivering hardware based tokens and 2. making it easy for web servers to implement webauthn. These 2 ways are really just different sides of the same coin.

  3) And as a last note, of course,in our reality, 2 step auhorization(SMS based) increases security from most of hackers(i.e. in case our passwords are stolen) , but the reality turnes out to be, user who uses 2-step sms authorization (or, doesn't use 2step, but has entered own mobile number in his profile, as a recovery method) has increased security threat - for example,when hacker doesnt know your password, but is capable to hack sms (as opposed to the first category of hackers, when you have increased security instead). Quite a problematic dilemma.

A chain is only as strong as it's weakest link. If it's easier to hack someone's account directly or by "recovering" the account. The attacker doesn't care. A website needs a strong primary way of authenticating it's users, and if it chooses to implement recovery. That needs to be secure too.


Does TCP/IP expose critical infrastructure to added risk?

TCP/IP is a best-effort protocol. It is very efficient at maintaining connectivity in adverse conditions (including use of nuclear weapons). It offers no guarantee of communication, but, when you come down to it, no system can (all communication systems involve using some kind of hardware, which may fail).

The problem with TCP/IP is not with TCP/IP itself, it is with the others ("Hell is other people"). One very interesting aspect of TCP/IP is that it is what the Internet runs on, so, if you do TCP/IP, you can easily use the Internet infrastructure, rather than having to build your own. A transoceanic cable is a bit expensive... so switching to TCP/IP is a cost-killer. Unfortunately, you are not alone on the Internet. If you use the Internet infrastructure for your communications, then, necessarily, you expose your communications to whoever roams on the Internet. As some security specialists like to say, you have "enlarged your attack surface". Cryptography (i.e. SSL) can help to keep your data confidential, but TCP/IP is such that denial-of-service are possible (if only by clogging the tubes).

So it is not really a question of TCP/IP or not. It is a matter of sharing the infrastructures, vs using dedicated links. For instance, the Internet2 is a TCP/IP-powered network which is separate from the mainstream Internet. Sharing infrastructure makes your more vulnerable -- but dedicated links cost a lot. Choose your poison: risking to see your communications disrupted, or not being able to communicate because you wanted dedicated links but could not afford them.

(In the Inca Empire at the beginning of the 16th century, there was a network of roads with dedicated lanes for messengers from the central power. Building dedicated lanes and guarding them -- trespassers could be beheaded -- was very expensive, but the Inca still found it worth the effort. Your question about TCP/IP is really the same situation, only with 400 years of additional technology.)


Multiple devices encrypting data using the same key?

I feel like this question deserves the standard "Don't roll your own" (also here).

I want to implement a service that can't read the data you store there.

Unless I'm grossly misunderstanding your question, you're trying to implement what we call "end-to-end encryption". This is something that is both surprisingly tricky to get right, and has also been solved many times. That wikipedia page gives a bit of the history and pitfalls associated with E2E Encrytion. I would also suggest that you base your implementation on the Signal Protocol, here are some sources:

Blog description: https://medium.com/@justinomora/demystifying-the-signal-protocol-for-end-to-end-encryption-e2ee-ad6a567e6cb4
Formal protocol description in section 2: https://eprint.iacr.org/2016/1013.pdf
Project page including link to source code at the bottom: https://signal.org/docs/


Botnets reach out to a Command and Control (C2) server - typically a range of servers to help mitigate server takedown issues.

When they connect to a C2 server, the server may chose to initiate a function in the bot - for example to take part in a DDOS attack - or may chose to update code within the bot.

Clever bots will have the ability to rewrite themselves (or part of themselves) in memory as well as being able to update whatever file(s) the bot uses. Some bots only exist in memory and are lost on reboot.


Yes, there certainly are circumstances that require programmers to hold security clearances.   The most common is when working for directly for the federal government at any of a number of agencies including the Department of Defense, Department of State, FBI, NSA, and a number of others.   In the private sector, you'll most commonly see clearance requirements for jobs working with defense contractors, though it could feasibly be a component of a job for any government contractor.

In order to obtain a security clearance, there must be a necessity.  It's not like a certification that you can get just to make yourself more employable...It must be obtained in concert with a project or position that requires you to be handle classified information.   Classified information could mean anything from the contents of sensitive communications, to plans, to specifications of weapon systems, even down to the implementation details of software that serves a sensitive purpose.  Clearances also don't last forever.  Not only is periodic re-certification required, but if you leave the position that requires you to hold a clearance, it will eventually expire, assuming you don't take another position that also requires clearance, of course.

Clearance is not something you can pursue as an individual.  It must be justified by the agency or company that you work for, based on the fact that they already have programs or contracts in place that require them (and therefore you) to deal with classified information as I described above.

For additional information on security clearances in the U.S. (the country for which this answer applies) the State Department website has details.


How to make it harder for a VPS provider to access my data?

Buy a VPS (the StorageVPS), create a 50GB file full of zeroes, export this file using SSHFS.
Buy another VPS (the ApplicationVPS) on another jurisdiction, mount that file, use LUKS to create an encrypted filesystem.
Use different identities for each one, so neither one nor yourself are on the same country (or group of friendly countries).

If the admins on StorageVPS get that 50GB file, it's just a large blob of unreadable data. They don't have the LUKS key, so they cannot decrypt anything. The admins on ApplicationVPS can have the key (they own the server after all), but being on another jurisdiction will complicated things a little for the government trying to read your data.

You will have latency issues, but your data will be a little safer.


Dataflow diagram - how far do I need to drill down?

1) I recommend starting with the diagram you have, and expanding it only when or if you find an ambiguity, a place where there's an additional boundary, where you have to ask "how does this work" to understand an attack or defense, etc.

I don't know what this refers to: "The SDL Threat Modeling guidelines state that I know that my DFD needs more detail when there is still a trust boundary in the DFD".  I owned those guidelines for several years, and I don't think that they said that (while I was responsible.)  Could you add a link?

2) Are permissions on each CRUD operation always the same?  If you have to expand on them to clearly communicate how the software works, then a diagram that shows the separate operations is a helpful communication tool.

Fundamentally, the work you do is supposed to help you understand, communicate and analyze effectively.  If there's work that someone ("the SDL TM guidelines") is telling you to do, and you don't think you need to do it, perhaps do a small experiment.  Then either you'll be surprised, or discover that in that instance, you don't need to go a level deeper.


Is there any way or tool to check whether a particular iOS app is implementing SSL Pinning functionality?

Using Burp is a good way to test it. But don't forget to import Burp's CA certificate on the device so that it is trusted by the device. Visit http://burp in the device's browser and download and install the certificate.

Most apps will now work over SSL and you can see their traffic in Burp. But apps that still fail are doing more checks, i.e. 'pinning'.

You can do the same using mitmproxy. In that case, visit mitm.it in the browser to import mitmproxy's CA certificate into your device.

Edit
It occurred to me that in Burp, you are not seeing the failed connections that the apps tried to make - you will only see successful ones. What I use to solve that is a tool called mitmdump, which is like a basic version of mitmproxy (mitdump comes with mitmproxy). It will not only show successful connections but also what SSL connections were refused by the client, so you will know what the app tried to do, and you can see that it was the app that refused to go any further.


If site provides MD5 to check file, can't the comparison string also not be modified?

Basically yes, you’d need to pass the MD5 checksum out-of-band through some other trusted means of communications, for example that the other party sends it over registered mail or something.

So it’s mostly to check that the file you’re downloading isn’t corrupted, and it does protect against some amateurish attacks, where a script kiddie managed to change the file, but not the site where the download link resides for example.

To truly protect against an attack like this, you’d need to use private/public key pairs, compute the hash and encrypt it with your private key. That would make sure that anybody that has your public key could verify that the hash you’re comparing the file to for integrity is still the hash you published, as it would decrypt using your public key.


typical purpose of self-signed certificates

While with Let’s encrypt offering certificates free of charge and easily today does take away the “it doesn’t cost anything” argument, there are still reasons why self-signed certificates can be useful, for example

for testing purposes (no CA is giving you a certificate for your local domain like testing.testenv.cooperation)
on local networks (to secure routers’ web interfaces, for example.),
as client certificates,
for S/MIME,
countering the problems of CAs in general.

The only real difference is that a CA-signed certificate is (usually) trusted without prompting the user for input while a self-signed certificate does need the user to validate it and put trust to it - for example by checking the fingerprint through a trusted channel. Once trust has been put into the self-signed certificate, it is as good as a CA-signed one (not counting rollover issues).

Self-signed certificates might come in handy when someone is not trusting the CA to not create a certificate for a MITM, for example.

Another big application of self-signed certificates (or more generally “non-CA-signed certificates”) can be client certificates: A web application can create certificates for authenticated users and use them to authenticate them from that point forward - certificate-based authentication is way better in terms of security than traditional username/password schemes and gets used often for B2B applications as well as mobile applications.

Using self-signed S/MIME certificates makes S/MIME about as convenient as GPG with the need to validate certificates manually (see above), but there are edge cases where someone without trust in a CA might have access to S/MIME encryption but not GPG (iPhone users, for example, as well as some corporate email clients)


Prevent cold boot attack on running laptop by overwriting ram

Yes, you can use sdmem tool for your purposes.

If you use only bash without any desktop environment you can simple add your command to $HOME/.bash_logout script.

In case of using GDM you can try to append sdmem command to /etc/gdm/PostSession/Default file.

Also you can to look this and this.

Good luck!


nmap Not Working with CIDR Notation on LAN

You are missing the final segment of the IP address.

It should be 192.168.1.1/24 this basically says to NMAP scan the entire class C network space of 255 IP addresses.

This is correct CIDR notation and assumes your LAN is on 192.168.1.

For more info on CIDR check out the Wiki: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing


Best Practices for exporting sensitive database data and transforming it whilist keeping it encrypted?

I would generally be more concerned about the unencrypted Excel Spreadsheet with sensitive data 'getting lost' than the temporary file, which can be dealt with a good procedure stating that it must be deleted immediately after generation.

Anyway, here are a few ideas:

shred the temporary file after processed.
Store the file on a ramdisk. For instance /dev/shm is always in-memory only¹ (sometimes /tmp too). If the temporary file is written there and forgotten, it will be gone on reboot.
Boot a live disk to perform the transformation.
Do not use temporary files but pipes. Using some command-line trickery (and depending on your data!), you may be able to get the desired outcome avoiding temporary file, eg. mysqldump --skip-extended-insert sensitivedatabase | sed -n -e '/^INSERT.*VALUES(//p' -e 's/);//' }' | gpg -e -r recipient > encrypted-spreadsheet.csv.gpg
Use a service that already exports the data. If this data is already handled in a web application, add the ability to the application to export it in the final format (we are actually moving the problem, but if that application is already handling this sensitive data in a way deemed secure, it makes sense to incorporate this feature there, too).

¹ Nitpicker's note: it may get swapped.

As for the other questions:

  is it possible to do the same thing with an encrypted directory or encrypted volume, that can be "scrubbed" automatically, after a certain period of time

You could have a solution that automatically unmounts or deletes temporary files somewhere. But it seems overcomplicated. I would make a script that performs the full exporting process, and that scrubs the unencrypted temporary file as soon as it is no longer needed.

I have no idea what you mean with the encrypted csv moving over the network using HTTP part.

  And also what about allowing an approved running process to access the information but not allowing it to be copied elsewhere? That sort of thing sounds in the domain of permissions / ACLs to me.

You certainly can do that. Be that a script, embedded on the web application, etc. If you get fancy, all of this could use selinux labels to enforce the process.

  Is it best to have a designated machine for doing this and limiting it's access to the outside world using a separate subnet / firewall / proxy or some combination there of?

This probably will depend too much on your specific case and the way of transformation for giving a generic answer. Obviously, the most isolated, the better. But as mentioned, I would start by questioning why this highly sensitive data needs to be given to someone on an Excel Spreadsheet, to begin with.


How Likely Is It For A Virus To Spread From A Linux VM To The Windows Host

Depending on your setup between the host and the virtual guest there are a few ways that a worm or virus could propagate.

1) Simple networking.
- If you have the networking adapter enabled on the virtual and the host can interact with it, then yes. A piece of malware that was multi-OS could propagate. Alternatively, if the malicious code was written in a cross-platform engine like Java, and you run Java on both the guest and host. This could be from setting the guest networking to host only, or host networking.  Technically possible with any enabled networking, but more likely with those two. Nat and Bridged form the connection to the host's NIC differently.

2) Sharing enabled.
- Having the host files or the clipboard even be writable to the guest can allow for an escape  or evasion tactics. VMWare shared folders had at least one CVE published for escaping the guest via the shared folders function.. 2008-0923 when I searched it, but there might be more.

3) Driver based
- Venom by crowdstrike showed how to do a Virtual escape based on the floppy driver being enabled by the guest. There may be similar vulnerabilities for other drivers.


When logging into my work WiFi (we are allowed to do this) what exactly can they see?

If you use plain HTTP, then of course they can read everything. But the major sites like Google and Facebook don't support HTTP, only HTTPS.
Technically it is possible that they fake CA certificates, implement a man-in-the-middle and read all your traffic. But this is possible only in case they control your phone an install their certificates or if they trick you to install one of their certificates.
In a normal case there are many preinstalled CA certificates on your phone. If you don't accept their certificates (certificates faked by your company, in case your company fakes them), then you can be sure that your traffic to the sites in public internet cannot be read. What they see is only target host and port, the amount of data, duration. Based on timing and data volume in some cases it is possible with high probability to identify the data type like text messages, images, music, or videos. But not the content itself.


Should a space in a password count as a symbol when checking for complexity?

From a complexity perspective it doesn't matter whether you classify a space as a symbol or in a class of its own, the more characters that can be used in a password the harder it will be to crack, provided people use the complexity to its full potential.

From a practical perspective given the code above your best bet is to add it to the symbol list, as if you added it as a separate line you would make it a requirement to put in a space, which would defeat the purpose as that would be a gift for anyone looking to crack your passwords - they already know one of the characters.

I must point out that the argument you use saying that "Ab1   " isn't a good password would go for any of the other symbols you allow as you code would treat "Ab1@@@" the same way. "AAAb1 " and "Abbb1 " would be equally permissible, and no stronger either.

My main recommendation for you would be to require longer passwords as 6 characters is pretty weak, no matter what complexity requirements you have. 8, or preferably 9 characters would be orders of magnitude stronger.


Sign GnuPG master key with own X.509 certificate?

Can I use my X.509 certificate to sign my personal GnuPG master key?

Technically, yes, you could use the private key associated with your certificate to sign the X.509 public key, as a statement of authenticity from the X.509 cert. However, I suspect you're really asking "is there an existing integrated implementation of this which is ready to be used?", and the answer  to that (as far as I'm aware) is no.

  Will recipients be able to use the CA's certificates to verify that the public key is indeed mine?

Assuming you're talking about using the CA certs to verify that the PGP public key is yours, no. You have to distribute the public part of your X.509 certificate (what we would typically just call "the certificate" - the private part is usually called "the key") to all clients who want to use it to verify anything. In SSL/TLS, this distribution happens at the start of the connection, after the ServerHello packet is sent - the server directly provides the client with its certificate. In your case, you'd have to work out some way of distributing your certificate to people. You'd also need to be able to distribute the signatures, which wouldn't be attached to the PGP keys themselves (although you could likely jury-rig the signatures into the same extensions that WoT implementations use).

  How does this compare to current web of trust expansion methods such as the key signing party when it comes to the trustworthiness and authenticity of my public key?

It's more cumbersome, lacks a real implementation, and merges two ecosystems that are designed to be separate. Web of trust allows other users to sign your public key with their private key, and publish those signatures.

As a scenario, imagine that Alice and Bob live in the same town, but I moved away and can no longer come visit. We all talk over email, signed with PGP. Before I moved, we all got together and exchanged public keys in person. Alice has just suffered a disk failure and didn't make a backup, so she has lost her keypair. She creates a new keypair, but I don't have a way of validating it. However, I trust Bob. He signs her public key with his private key, and distributes that signature. I can then trust Alice's signature by proxy, without ever validating it myself.

Introducing X.509 into this is painful. The certificate distribution alone is a major headache. If the CA goes rogue, they can issue arbitrary CAs and start socially engineering people into accepting new cross-signed keys. The other problem with an automated approach to key distribution is that it only takes one CA to go rogue - this is currently the case with PKI (especially HTTPS) and it's a major problem that we don't have strong solutions for (aside from certificate pinning).

  Would this provide enough security for someone who doesn't know me personally to sign my master key?

That's subjective. My personal answer would be no, because I don't trust the CAs to be foolproof. It makes a certain amount of sense to use web-of-trust within the PGP ecosystem itself, because the sphere of influence is each person's system, key changes are infrequent, and the system is designed from the ground up to work with email. Introducing X.509 and PKI just turns everything into a mess, and moves the sphere of influence out to third-party CAs.


How can I allow access to encrypted data if only 2 out of 3 users provide a secret?

It is called threshold encryption (or, here, decryption).

A well-known scheme is Shamir's Secret Sharing. It allows splitting a secret value into n shares, such that any t shares are sufficient to rebuild the secret. n and t can be chosen at will (although you will want to have n greater than t in practice). For the threshold encryption problem, you apply Shamir's scheme on the decryption key. When t share holders meet, they can rebuild the decryption key, and then decrypt the data.

Though Shamir's scheme is fine (in fact, it is provably secure even against attackers with infinite computational abilities -- very few cryptographic algorithms can claim to be similarly secure), it has a limitation which is the following: it rebuilds a secret. This makes it somehow "one shot": if the share holders rebuild the secret, then they have the secret. Each of them will be able to do further decryptions alone by simply remembering the rebuilt secret.

Depending on your context, this may or may not be a problem. For instance, there are voting systems using homomorphic encryption (e.g. with ElGamal), where the encrypted votes are tallied together without decrypting them (that's the point of homomorphism); but the final count must still be decrypted. We want threshold decryption here: several authorities must collaborate with each other to do the decryption. That way, the authorities keep each other in check. However, if they learn the private key itself in the process, then each authority will thereafter be able to decrypt individual votes, which defeats the whole purpose.

If this issues apply to your context, then you must do more mathematics. There are threshold decryption schemes which allow, for instance, a threshold ElGamal decryption, such that t share holder must talk to each other for each decryption instance, exchanging "partially decrypted messages". The private key is never really rebuilt, but its action (the decryption) is gradually reproduced.

There is a lot of theory on threshold cryptosystems, with various characteristics (how many shares, what possible threshold values, does the scheme resist well when some share holder actively cheat, how many messages must be exchanged, and so on). If your problem at hand can be solved with Shamir's scheme, then, by all means, go for it. It is reasonably simple to implement (in particular, sharing files is easy if you do all computations in GF(28)).


Is it a good practice to connect to my IP camera using a VPN?

IOT devices including baby monitors are infamous for a lot of security issues. Majority of them even allows an unrestricted, unauthenticated access to the camera feed if you port forward it through the router [And surprisingly, they advice you to IP forward them as well!].

I agree with your concerns and believe that it would be a very good idea to restrict access to the device from any other network other than the local network. Even if the interface is password protected, they are likely to have authentication flaws as these devices infamous for such flaws.

Have a look at the Shodan database nd you will get an idea how many of these devices have known back-doors and default accounts enabled. From shodan you can even see a lot of such accessible cameras! Creepy, isn't it?

https://www.shodan.io/explore


Deriving 2 keys from user password - one for login - one for encryption?

I think the duplicate I proposed should tell you "yes, you're going about this in a reasonable way", but there are a couple points that I think are worth addressing separately.

  The 3 salts used in steps 2-4 could be derived from the email by using SHA3-512 and take the necessary length of bytes needed for those functions?

Salts should not be reused, and they should not be predictable. By using a hash of the username, the same salt will be used whenever a user changes their password. It also allows an attacker to trivially predict the salt that will be used and start generating a rainbow table in the hope that a future leak will allow them to make use of it.

In the case of the login key salt, since it has to be used client-side prior to logging in, anyone who knows the username must be able to retrieve the salt from the server anyway, so generating the salt from the username may not be a deal breaker here, however it would still be best to avoid using the same salt when a user changes their password. The encryption key salt should be randomly generated in order to prevent pre-computation of rainbow tables, which means it needs to be stored on the server (unless you're ok with users not being able to change browsers/computers).

If you compare this to a normal app that just sends the password to the server, this isn't really any less secure to outside attackers. For a rainbow table using the login-key salt to be useful, someone would have to obtain the user's login-key, which in other apps would be the password itself.

If the encryption key salt is only sent to authenticated users, then the only rainbow table that could be generated would be for the user's login key. If there is a database leak, then the server-side bcrypt hash of the login key will have a separate random salt that the rainbow table won't be useful for, and the encrypted data will be encrypted using the encryption key salt that the attacker wouldn't have prior access to, so allowing anyone to access the login key salt shouldn't pose too much of a threat.

Of course, if the server itself is malicious, nothing prevents it from trying to crack the password, but this isn't really avoidable.

  I was thinking it is important that the server has no information how to decrypt the vault.

While that certainly sounds nice, unless your users take extreme measures (ie auditing the code and verifying it hasn't changed every time they load the page) they'll still have to trust the server to some extent. It's the server that sends them the JavaScript every time they load the page, and it would be easy for someone malicious in control of the server to modify the code to have it send them the encryption keys.

Client-side encryption with a key known only to the user is useful to mitigate the damage done if the server is compromised in the future, but if a user connects to the server while it's compromised/malicious they're probably going to be out of luck.

  Thus should never know in any point in time the secret key for the vault. By just using one password for login and encryption sounds not reasonable?

Running the password through bcrypt and then HKDF client-side with separate salts for the encryption key and authentication should be sufficient to solve this problem. Just be aware that, historically, JavaScript hasn't been a good choice for password hashing due to its speed. If a native implementation is 10x faster than a JavaScript implementation, the JavaScript will have to run 10x longer for the same security. A WebAssembly implementation may work better, but benchmarking is recommended.


Could we make an impervious server with read-only software and no root access?

This would prevent the server from executing code that was written by an attacker, that does seem like a good idea, but another problem remains.
You'll have to include some software in the beginning, when you create the server. Every piece of software has a fault somewhere, no matter how many tests you go through. If you write this software to the server and 2 months later, an exploit is found where the attacker doesn't inject code (since that is not possible by premise) but rather uses existing code in the software to break something, by sending data the coder did not expect.
Since your server code can't be changed you now have no way of applying the security patch.


How to prevent sysadmins tampering with code?

There's actually no control in the application itself. Often how this is checked in practice is by employing two-eye principles for deployments (no one user can access or change the system on its own) or they use solutions which perform full command accounting like Powerbroker or CyberArk.

Note that these systems should then also be managed by independant teams.


Does code obfuscation give any measurable security benefit?

There are two benefits to code obfuscation:

It weeds out the shallow end of the attacker pool.  Script kiddies who struggle to make sense of your code will go somewhere else.
It increases effort required of skilled attackers.  No matter how skilled they are, obfuscation is cheaper than de-obfuscation, and the result is generally less comprehensible than the original (variable names will remain generic, for example, where the originals were descriptive).

@SteveSether is doubly right in his comment - actual measurements will be almost impossible to find, and many code bases are obfuscated for proprietary reasons* rather than security reasons.

But for both security and proprietary reasons, code obfuscation's value is tied to its asymmetric quality - it's cheaper to obfuscate than it is to de-obfuscate.

*By "proprietary reasons" I mean "the desire to keep one's code and algorithms more private, or harder to reproduce, in the interest of maintaining competitive advantage in the market."  Companies and individuals are both prone to this tendency.


I personally prefer OSSEC. It is a free, open source tool backed up with commercial support.


Can I know who tried to login to my Google account?

No, there is no way for you to know who it was. Might not even be a person, could just as well be a hacked computer that is part of a botnet trying to brute force random accounts.

The IP could tell you what ISP the person uses, and a vague geographic location that is not very precise. But that is only if who ever it was didn't use a VPN, Tor or some kind of proxy. So in practice even that info might be wrong.

Really, I wouldn't care to much about this. Make sure you have a strong password that you don't reuse and turn on two factor authentication. Stopping people from gaining access to your accounts is a much better strategy than trying to track down those who tried.


My understanding of how HTTPS works (gmail for example)

Yes, you're on the right track!  But things actually work a little bit differently than you outlined.

In particular, Steps 4-8 are not quite how SSL works.  SSL works a little bit differently.  Here is how it actually works (I'm going to make some small simplifications, but this should get the gist of the idea right):

The Gmail server sends your client a certificate.  The certificate includes the Gmail server's public key, and some evidence that this public key actually belongs to gmail.com.
Your browser verifies the evidence in the certificate, to confirm that it has the proper public key for gmail.com.
Your browser chooses a random new symmetric key K  to use for its connection to Gmail.  It encrypts K under Gmail's public key.
Gmail decrypts K using its private key.  Now both your browser and the Gmail server know K, but no one else does.
Anytime your browser wants to send something to Gmail, it encrypts it under K; the Gmail server decrypts it upon receipt.  Anytime the Gmail server wants to send something to your browser, it encrypts it under K.

Your Steps 1-3 are roughly right, though not exactly right, and the details depend a little bit upon what browser you use and what URL you type into the address bar or how you get to Gmail in the first place -- but what you wrote is close enough for understanding the basic concept.  Good enough for government work.

Here is some additional reading for you:

How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?

How do the processes for digital certificates, signatures and ssl work?

Purpose of certificates signed and trusted by CA

Why is faking SSL certificate difficult?

Why is HTTPS not the default protocol?

Is visiting HTTPS websites on a public hotspot secure?

I think those articles should give you an excellent understanding of SSL, how it works, and why it is designed the way it is.

If that's not enough, you must have more more more, here are some articles from Wikipedia:

How certificates work

How SSL works

However they probably have way more technical details than you ever wanted to know, and they aren't a great first introduction to the concepts or the basic ideas.


truecrypt second encryption of the master and XTS key with a back door password

You should learn to read further before panicking:

TrueCrypt 7.0a is a highly secure program for encrypting containers based on the current state of
the art in cryptography. We found no back door or security-related mistake in the published source
code except for our attack on keyfiles. If you use this program in a secure environment such as
Ubuntu privacy remix you may assume with high certainty that no one can get access to the data
stored in your containers as long as they are closed, the passwords are really good and the
attacker doesn't apply highly advanced methods below the layer of the operation system, such as
BIOS rootkits, hardware keyloggers or video surveillance.

That's from the conclusion at the end of the document.


These settings you mention are related to SSH. On the shell itself (e.g. bash) you can also set timeout settings.

To see the specifics that Lynis is testing in this case, have a look at the lynis.log.


Older chargers used to just be a simple power supply - little more than a diode bridge, a capacitor and a voltage regulator IC. They supplied a steady voltage to the phone, often +5V. When USB connectivity arrived with modern phones, +5V became a standard and the supply pins on the USB header were used for charging just the same. The two data pins would be left floating or tied to ground, and would not be used.

These days things have changed. Modern phones are power-hungry smart devices, with large batteries. The old USB standards heavily limit the amount of current that can be supplied to a device. On a USB 1.1 port, you could draw up to 100mA of current on the +5V line. This equates to 0.5W, which certainly isn't much when charging. USB 2.0 increased this to 500mA, and USB 3.0 increased it further to 900mA. However, the actual allowed power consumption is not as simple: when just plugged in the maximum a device is allowed to withdraw is only 100mA / 150mA for USB 2.0 / 3.0 respectively. The device must designate itself to a particular type, as must the dock to which it is plugged into. This is called a negotiation.

There are three main types of power state for USB:

No Dead Battery (NDB) mode - allows 100mA (150mA on USB3) to be drawn when plugged into a device without any negotiation. No data may be transferred.
Host charger mode - allows 100mA on USB 1.1, 500mA on USB 2.0 and 900mA on USB 3.0 after the device has been registered with the host, and full duplex communications can occur. This is the "normal" mode most devices will be in when plugged into a computer.
Dedicated charger mode - only defined for USB 2.0 and 3.0, and allows 1.5A on a dedicated charger device. Whilst in this mode, no data may be transferred. However, the device must negotiate this mode with the charger.

Notice that only 150mA may be drawn by the device when no negotiation has occurred. This is a safety feature, as over-current protection on a device may involve surface-mount fuses that require de-soldering to replace. As such, if a device tried to pull 1.5A on a USB 1.1 host that only supports 100mA, you'd likely melt the host. As such, we have to do proper negotiation, which involves some data transfer.

Here's where things get fuzzy:

The negotiation phase may be implemented in hardware, firmware or software. Usually the first step is hardware, then the next step is firmware, and the final step (OS recognition via PnP) is software.
The data involved in the initial negotiation handshake doesn't (as far as I'm aware) involve any arbitrary length buffers. It's this stage that involves the power negotiation.
The data involved in the full Plug-n-Play negotiation is complicated and most certainly does involve arbitrary length buffers.

As such, modern dedicated chargers usually have a small microcontroller or dedicated USB host chip to deal with the negotiation phase. This means there is usually a firmware-based attack surface on the charger, and most definitely on the device. However, some specialised chargers (e.g. iPhone) cheat the specification by using detection tricks (e.g. capacitative sensing on the data lines) to make the charger production cheaper, and therefore don't need to do any data transfer. This may or may not be a violation of the USB specification, but big companies tend to be able to get stuff like that past regulatory bodies.

The wireless charging side works almost the same way, except the actual transfer of current is done via an oscillating electromagnetic field. The negotiation works in the same way, just over an NFC-style communications channel. If you could inject data into that communications channel, you might alter the way the negotiation works, but I doubt you could do anything interesting without violating the protocol. An interesting avenue of research would be to see if any devices have buffer overflows or similar issues in the protocol.

So, in conclusion, you may be able to find an exploit for a device, but it's likely to do nothing more than temporarily brick the USB controller IC on the device. Alternatively, you could replace the charger with an active host, and use it to fully negotiate with the device and send commands to it. This is especially dangerous on iPhone and Android devices that have USB debugging enabled, as it allows the device's memory to be accessed.


Yes, a scammer can charge you differently and that will not be covered by the normal 'unlimited' plan you have subscription to.

But in most of the cases, those are special numbers that use other prefixes instead of the area code. You probably know that most 0-800-numbers are free and available in many countries. Well, just like that, the 0-900-number can be numbers with special tariff that will charge a few times the normal fee. Those are not covered by your subscription and will be charged separately.

Using a standard phone number in over-charge mode is also possible, but a lot harder to accomplish by a scammer.


Can you establish a weak/common password policy in Active Directory in line with NIST guidelines?

I'm not an Active Directory expert, but from what I read so far, this should not be possible with AD alone. You might want to take a look at this Microsoft article. It explains how password polices are set up and all that. There is no mention of password dictionaries or blacklisting.

I also found this (mabye outdated) answer in the Windows Server forums. The accepted answer there also says, that this is not possible. This is a post from 2011 though.

There are third party tools which claim to accomplish this. I have no idea if these will actually work and I don't want to advertise them, so I won't link them here.


Does encrypting HTTP header value provide additional security?

There is no general response for this but it depends on what exactly you are doing and what kind of "additional security" you aim for.

In your case it looks that you just replaced a plain text password with an encrypted password. Unless you have some replay protection baked into your unknown encryption algorithm the attacker could just sniff  your encrypted password and replay it later. Which means it does not really provide additional security if your goal is to make authentication more secure. If your goal is instead to only hide the plain text password to make password reuse attacks harder then encryption might help.


Strong authentication over insecure links

If your encapsulating layer is insecure, then you can adapt by creating a secure layer within that if you have a known public key ID for the remote host.

Since IP is insecure, we run SSL within it. Since your SSL sessions are forcibly terminated to an unwanted hosted making them insecure, run another secure layer in them such as SSL. SSL over SSL, SSH over SSL, or any other combination of tunneling should provide a trustable connection as long as you verify the host key.


Securing small volume distributed web services

Per several of the comments, the downside to this solution is the local installation of a publicly available web service.  The initial requirements just to allow connectivity is greater than the return on the service, you have:

Public connectivity requirements
Security requirements, minimal maybe but litigation still can happen over the smallest of issues
Certificates for each location:  no, self signed is inappropriate and again, a bad choice especially if the web service is used by mobile devices (who hate self-signed certs)
There is always an IT maintenance SLA somewhere and dispersed installations means dispersed infrastructure and troubleshooting management.

We could go on with other issues, from patch management, to janitors walking in and turning off critical infrastructure.

Per Schroeder, using a lightweight cloud service (AWS or Azure), you can create a single web app space and tenant the application as a subscription so turning up a new taxi service is as simple as you develop it within the application.  it can be a subdomain of the parent service, it can be a separate VM, or it can just be a logon-isolated app.  But the benefits of maintaining a single web service in the cloud starts with:

Single troubleshooting location
Easy application availability (redundancy is just one of those cool Cloud things)
-Infrastructure that eclipses small business on-premise services
Built-in monitoring, DNS, routing, and networking services.  This is the big one that you don't want to deal with for one-off small office issues.
Documentation and support - when issues arise, you at least have someone to talk to, compared with vendor A for internet, vendor B for basic networking, vendor C or yourself for dev work (or you're contracting it out at a premium)

Cloud is just the better way to go for these solutions.


Storing original length of encrypted message

Yes, storing the length of the original message in plain text will make your message slightly more vulnerable to a brute force attack, but it's not significant.

Assuming a suitable key length and suitable algorithm, there will likely be so many keys that would provide the same decrypted message length that knowing the length alone will not provide a suitable means to automate an attack. The attacker will need to know more information.

I wouldn't worry about it as long as you have a cryptographically strong key (length and randomness) and algorithm.


Asking questions randomly from a set of questions instead of a password?

Some issues with this:

Signup would take a long time. That would be a major deterrent for many websites.
Privacy, you get a lot of information about someone and if it's not something that everyone knows then obviously it's personal. It's one thing if your password table ends up on the streets, it's another when I can find out all kinds of tidbits about someone's personal life. Which brings me to the next point.
Re-use. For passwords at least you have the option to use a different one, but the answers to the questions won't change for the next site. If more websites would do this and just one gets hacked, what's preventing anyone from logging in left and right? Or even malicious administrators looking at the answers, either before hashing or after some form of bruteforce attack.


Risks associated with distributing encrypted private key with our software?

There are cases where you can actually distribute the private key (even unencrypted) but they are really borderline (for instance, you might want to lower the amount of ssl connections your server will accept before even performing client authentication but might not have the possibility of properly issuing each client his own client auth cert).

It doesn't looks like that's what you're doing here, though: that certificate is a wildcard server certificate certificate for the timetellbv.nl domain. It makes little sense to use that for client authentication (you would be better of using your own CA for that) so you're probably using it to serve file.

So, the next question would be: what type of deployment are we talking about ? If you're talking about a single-site deployment (i.e. that is your own certificate and you're deploying your own app on your own server), then it might be bad practice to place the certificates in the deployment package (see the question you linked), but it's not making your whole security invalid.

If, however, you're deploying an application from or to a third party, then this is a big no-no: the only way to make use of such certificate is to use it incorrectly: it is improper for identifying ANY system but the ones under the *.timetellbv.nl domain and shouldn't be used.

(As a side note, https://www.timetellbv.nl returns an invalid certificate: the DNS name does not match)


Possible to inject in the middle of a ROOT NOPASSWD command with a wild card?

Well after beating my head against numerous commands, I finally found that I could escape the wild card and cat out /etc/shadow
...With a little help from this cheat sheet

https://gtfobins.github.io/
https://gtfobins.github.io/gtfobins/ssh/#sudo (more specifically)

$LFILE=/etc/shadow
Success: sudo /usr/bin/ssh user@localhost -F $LFILE /path/to/bash/script.sh
Hope this helps someone in the future. :) Cheers!


Would they be able to negotiate a cipher suite using a cipher defined for TLSv1.0?

Yes.
RFC 7568 Deprecating Secure Sockets Layer Version 3.0 was just published (2015-06-26).
(The draft to this RFC was affectionately known as draft-ietf-tls-sslv3-diediedie.)
Quote from RFC 7568's Section 5: Limited Capabilities:

Though SSLv3 can benefit from new cipher suites, it cannot benefit from new cryptographic modes and features

So, yeah, technically. But I don't know if you'll find any implementation to actually do this.


Firewall Considerations with PGP Universal

To be honest, opening these ports on your firewall doesn't present that much risk at all, especially if you consider the tightest possible cases:

The key server ports - this is an outbound rule that can be limited to specific keyservers, but even if it isn't limited, it is still an outbound rule, so an attacker would have to ascertain sequence numbers and spoof a reply.

Similarly, opening port 443 presents the same risk as opening for desktop users.

Your most likely risks are presented from misconfiguration (as it is a complicated behemoth), but the firewall rules aspect is actually pretty straightforward.


Is a random keyfile more secure than a derived key?

If you generate a random key with no password, then its entropy (a measure of how long it takes to find the key through brute force attempts) is the size of the key. For example, if the encryption algorithm is a mode of AES-128 (a common choice), then a random key has 128 bits of entropy, meaning that it takes up to 2128 attempts to find it by brute force. (That would take more than a billion years with a billion PCs.) The risk with a random key with no password is that if an attacker obtains the key file, they can use it just as if they were you.

If you use a key that's derived from a password, its entropy will be a lot less. How much depends on how the password is chosen, but you have to rely on having chosen a strong password, which can be a problem if you have many users who can't necessarily be trusted not to pick Passw0rd. Furthermore, the attacker might obtain information about the password by watching you type or other “out-of-band” methods.

If you generate a key file and protect it with a password, you get the best of both worlds, in terms of confidentiality. The attacker would have to obtain both the key file and the password in order to obtain the key. Note that if the attacker obtains the key file, he can try to find out the password, but even then you might have a bit more time to change the key while he attempts to crack the password.

Depending on the application, entering an invalid password may either tell you that the password is incorrect without contacting the server, or may silently compute a wrong key that the server will reject. The latter is better because that means all cracking attempts must reach the server, and the server can limit the rate of cracking attempts. This way, even if the attacker grabs the key file, he'll be limited to the rate of attempts that the server allows, and you'll know that something is going on. If the password can be validated with the key file alone, the attacker can make his cracking attempts offline and can parallelize them over many computers.

Keep in mind that if you make it harder to find the key, that hinders you as well as attackers. If you use a key file, you must back up that key file. If you use a password, you must back up that password. If you use a password-protected key file, you must back both up.


Port scans: 'traffic denied' VS 'close - age out'

Some Juniper devices log TCP RST packets as age out. This is to do with how the ASICs handle the timeout - see here.

A RST packet would be expected behaviour when a SYN based port scanner is allowed through the firewall on a given port. SYN scanners send the initial SYN packet to establish the TCP connection.

For a closed port most systems would reject this by sending a RST packet (thus letting the client know and not leaving them to time out).
For an open port the client would respond with an ACK. The scanner then (usually) sends a RST so the server knows it can close the connection.
Worth noting this could also legitimately be a time out. I.e. a connection is established but no packets are received within the firewalls timeout limit.

If you are seeing age out on those ports it would suggest the packets do make it through the firewall. Without seeing more information from the log, firewall configuration or server configuration it is difficult to speculate on both why these are allowed through and how far through the connection the process gets.


What are the security risks of USB fingerprint scanners in Windows 10?

Good to hear to are considering biometrics and want to learn more about them.

Using a fingerprint scanner is generally considered (in a windows hello context) to be a convenience not an increase in security, however, I can envision several situations where security could be increased or decreased depending on the situation.

Potential issues

Fingerprint scanner are generally considered to be spoofable, meaning a sophisticated attacker could make a fake fingerprint or even use some other trickery to login as you. See this article
If someone makes a fake fingerprint of you,you can't change your fingerprint. This is a problem with all biometrics, they are tied to you and unchangable.

As to some of your other Questions:

It doesn't matter if you use a external USB one or the built in one on your computer, they work the same way. If malware is on your computer intercepting your devices then you are already compromised and the app could be recording your keystrokes or pulling your passwords directly.
Windows Hello treats your biometric data about equivalently to the "PIN" on your computer, a local replacement for your password. The biometric data is local to your computer, and is not synced to the cloud. Microsoft considers that someone is physically present attempting to login to your device to be a factor in the multi factor authentication scheme that justifies their windows hello approach.
Basically, if you have an attacker physically attacking your device between your uses, you are in trouble. They could break your fingerprint scanner, and install a tiny camera to record you typing in your password. Or physically insert a keylogger or a host of other attacks.
It could increase your security if you setup the fingerprint in a secure location and only after use your fingerprint in public places, then an observing attacker would not be able to get your password from recording you logging in for example.


Generating authentication token from PHP sessions

Rather than just hash, you should encrypt some values that can be decrypted by both your PHP and Node.js systems.

The data to include could just be:

Username.
Ticket expiry date.

However, since you are encrypting you could include additional details you would need to be available and these would remain private from the end-user.

These would be encrypted using AES and a 256 bit symmetric key that is known only to your PHP and Node.js applications. For a rolling expiration you should update the expiry date on every request and issue a new ticket. For performance reasons you could update less than this (say once the ticket has reached its half life). This is the encryption method ASP.NET uses for its authentication tickets.

So your token could be

AES-256(256bit secret key, username + "|" + (date-time + 20 mins))

After decryption you can check that the date-time value is in an acceptable range (i.e. the next 20 mins) - if not you should log this as a security event and this will provide reasonable protection against brute forcing. If you're storing this in a cookie as well as sending it via WebSockets you can make the cookie expire at the same time (bear in mind though that not everyone will have their clock set correctly so you might want to add in some extra leeway for the cookie expiration).

If you want further protection, encryption does not provide integrity as @GZBK noted, so you may want to ensure integrity of the decrypted value. This can be achieved with a HMAC of the hashed data. So your token would become:

encrypted_data = AES-256(256bit secret key, username + "|" + (date-time + 20 mins))
ticket = encrypted_data + "|" + HMAC_SHA256(256bit secret key, encrypted_data)

You can use Base64 encoding to represent values within your ticket.


Can my company see what HTTPS sites I went to?

An encrypted connection is established first before any HTTP requests are performed (e.g. GET, POST, HEAD, etc.), but the hostname and port are visible.

There are many other ways to detect which sites you’re visiting as well, for example:

your DNS queries (i.e. they’ll see the IP request for secure.example.com)
via network monitoring (e.g. netflow, IP to IP sessions, sniffing, etc.)
if the device you are working on is owned by the company and they have administrator access/privileges to view anything on the device (e.g. view your browser caches)

A popular way to evade a Websense proxy is to first establish a connection via HTTPS to an outside proxy (e.g. https://proxy.org/) and make your request from there.


Is the OAuth2 authentication code long enough to be secure?

Or is the length of the auth code an implementation detail left up to the authentication server?

Yes, the auth code is an implementation detail left up to the authentication server, but the OAuth 2 RFC has several design requirements - most notably:

Short code lifetime.
Code is usable once. Attempting to use it more than once revokes tokens tied to that code.

The "usable once" feature  means that even if an attacker can obtain/guess the code, any resubmissions to the auth server would (if possible) revoke tokens associated with that code. This is both good and bad. Good because it limits the attacker's window of opportunity. Bad because it could be used as a denial of service attack.

  The authentication code can be small: as little as 10 Hex digits. Is this really secure?

Yes. To mitigate against brute force attacks, code generation entropy needs to account for frequency of calls to the token endpoint (rate limiter can help) during its lifetime. For example, if we go with your 10 hex digits, code lifetime of 30 seconds, and attacker can submit 1000 guesses per second: probability of guessing is in the order of 1 in 270 million - you can further improve on this by picking a better character set than hex (16) such as base 64, and reduce the code's lifetime.


user of my wifi for texting when visiting my home

If you didn't setup your router to log all communication metadata you will not be able to find out what communications have been transacted using your wifi. The maximum of information you will be able to gather from a home router is a list of the MAC addresses that where connected to your wifi and even that depends on your router.


What is a good method to authenticate users and make sure they don't give their credentials to someone else?

You are looking for a technical solution for a social problem. That usually doesn't work. If you have a dishonest workforce who is collaborating against the company, they will always find a way to cheat the system. The only real solution is to fix the trust issues between your company and your employees.

But if you really want a technical solution, you might want to invest in a physical punch clock system and place it in some easily observable location where anyone with two punch cards will have a high risk of being caught.


Cheapest and tiniest acoustic isolation for smartphone?

As well as using a source of noise for drowning out the sound of talking in the room you should also use an insulated box. The insulation partially blocks the noise of the talking getting to the phone, and partially blocks the annoying white noise of your device.

Maybe open the walls of the cooler and fill the insulating cavities with sand, if you never need to move it or explain to anyone what it is.


Should we do request manipulation or network packet manipulation for SDN vulnerability analysis?

I would assume since the connection between the application and the SDN controller is over the application layer and that between the controller and the switches is over the network layer, you would require Burpsuite and Wireshark for request and packet manipulation respectively.


How do proxy servers protect their SSL certificates?

What you describe is not what is usually called a "proxy". The normal "proxy" is a machine which is close to the client, not the server; communications between the client and the proxy are not normally encrypted (they can be, but that's rare); and when the target server uses HTTPS, then the SSL is between the client and the server, the proxy seeing only the encrypted flow.

(There are setups in some organizations where the proxy does the SSL itself, as the client; such a proxy also rewrites URL in Web pages so that clients see only http:// URL, not https://. This has become less common nowadays because it breaks many applications and sites, in particular sites who assemble URL through some client-side Javascript.)

In any case, it would be wrong to think of firewalls in such a clear-cut way. A firewall does not ensure absolute security. Similarly, a machine with no firewall is not a free-for-all. A firewall is really a method to cope with sloppy administration on the machines themselves: it blocks access to some ports when the server to protect listens to these ports, while it should not.

The nicer way to say it is that a firewall simplifies administration since it allows blocking incoming connections at a single unified place instead of requiring strict regulation on each machine. Yet, a well-administered server needs no firewall to be secure.


Should a user be able unlock his own account after being automatically locked out?

As security practitioner (CISSP) we always have to fight with/work with/debate with the organization between the balance of confidentially and availability.

Therefore, in my environment we allow users to unlock their account if they provide sensitive information that an hacker should not know. It just created another step for hackers and to allow legitimate users to get back to work.

If you are looking for the most secure possibility, of course it would require a human to look at logs and manually unlock the account.

Depends on your environments needs, how many users, and how much overhead you can afford to invest in these tasks.

Best of luck, I'm available for additional questions.


Recently, our clients want to encrypt their files for one reason: " They don't want FTP server admin has access to their files".

With this requirement the encryption should not be done at the server side. Otherwise an administrator could just grab the content before it gets encrypted. And of course the management of the passwords/keys should also be accessible to the client only.

This leaves only encryption at the client side. There are several solutions for it, like password protected archives etc. Or, one could use PGP and help clients by setting up a private PGP key server to make exchange of public keys easier. The keys itself should of course by generated by the client itself and the private key should be kept at the client side.


SIM cards - Keeping my phone calls secret

I think M'vy gave the right answer in the comments, so I would like to expand on it in a full-sized answer.

Have a look at your threat model

People always say "I want to be safe". That's nice, but what do you want to be safe from? What is the possible attacker in your scenario, and what is their goal?

Are you afraid your employer might listen to your phone calls? Are you afraid the government is tracking who you are in contact with? Those two require radically different solutions.

Think about possible attack vectors

I will assume that your threat model is your employer tracking who you are in contact with. Different threat models require different solutions.

If you use the phone your employer provided you with, it's entirely plausible that your employer installed some spyware that listened to your calls and sent copies of those calls to them. It may not be legal to do so, but it's entirely possible.

If you use the SIM card provided by your employer, they are legally the partner of that contract. As such, they can an legally contact the phone company and ask for the log of conversation partners. This will list metadata of all incoming and outgoing calls, but not the contents of those calls. Depending on who your conversation partner is, this might reveal a lot about the contents already.

Think about possible solutions

The easiest solutions for both of these is to not use things provided by your employer. Mobile phones can be bought for less than 50 USD, some even as low as 30 USD. You already bought a pre-paid SIM card, so that's fine.

Keep in mind that this doesn't mean that you are 100% anonymous. Depending on the contents of your calls, you might be of interest to government organizations. In this case, you're on your own.


Can correlation attacks (end-to-end confirmation) be used as a defense?

So just like timing and data sizes are used to correlate from end to
  end on a Tor network to deanonymize a user, can the same method be
  used on a single device to monitor and correlate incoming with
  outgoing traffic.

Yes, it is possible to guess that the device is used as a relay if you can watch all its communication patterns. And the less traffic sources the device gets/sends traffic to, the higher would be the probability that your guess is correct.

  and if the data or timing is correlated then the server can deny
  login, a transaction, a service, etc.

Unless the "server" here is the only Internet gateway to this device, it is not in position to see all traffic coming to/from the device. Thus it will not be able to tell whether the device is used as a proxy.


Is there an entropy difference between hashing an encoded string?

It does not increase the entropy.

An attacker performing a brute force attack can simply apply the same encoding you are using before hashing.


If I'm using a SSL proxy, can the owner of that server decrypt and read my packets when I'm connected to a HTTPS website? (Password and etc)

Usually an Anti-Virus Software will create and install a Root CA certificate at your computer, which is capable of creating arbitrary certificates. These will be considered "trusted" by your computer, as the CA which signed them is trusted (the Anti-Virus CA).

At the time of you requesting a website, this will usually happen.

You request google.com
Your AV software will proxy the request
Your AV establishes the connection and validates the original google.com certificate
Your AV gives a forged certificate (which is signed by said Root CA) to your browser
Browser consideres is "trusted" as the root CA is trusted
Your AV has the key(s) to the Root CA and its certificated so it can read and re-encrypt all traffic

Otherwise, your AV software would have to somehow manipulate your system in an even worse way, as it is not capable of decrypting the HTTPS content (only the browser can (and anybody ripping the keys from its RAM)). Chrome recently implemented measures against AV software manipulating its code, as AV software is known to implement their own little bugs while trying to protect you (it's software nonetheless and therefore has bugs and attack surface).

Is AV Software capable of spying at you? Absolutely. It runs as a very privileged process as thus can manipulate a lot of things.

Will it protect you? If it detected the malicious content, yes. However, AV software can fail at detecting attacks, especially new ones, so don't rely on it alone as safety measure.


What are the arguments for and against having anti-virus on domain servers

Some people argue that installing an antivirus would in fact increase the system attack surface because to the vulnerabilities of the OS, you now have to add the vulnerabilities of the antivirus.

Another common argument is that antivirus could reduce system performance and stability.

In my opinion, these arguments are valid and true but you have to balance these facts with the increased security you could gain installing an antivirus.

How an antivirus can effectively increase the security of a domain controller?

In my opinion, if you implement and mantain good security practices you don't need an antivirus but cause this is difficult, installing an antivirus will cover you in some cases.


How does one securely create a MySQL database and user via the command line?

But isn't that insecure,

There is no absolute scale of "secure", indeed it is not even a vector or scalar property. (IT) Security is about ensuring that your technology does not do things it is not intended to do - while continuing to do the things it should. This is a very long winded way of saying you should have told us what the threat model is.

Leaving aside the many questions about how your application persists the pasword and whether it needs a password at all and the fact that your method is dependant on the root user not having a password....

Your current method will expose the password (briefly) to other users via 'ps' on Unix/Linux (and probably something similar on MSWindows - you didn't tell us what OS this sits on, but the 'bash' tag kind of implies Unix/Linux). And if it was run directly at the command line, will be present in audit logs and your shell history - although you said this was in a script. There are potential path and alias exploits a third party could use (if they have access) to subvert the behaviour - although is starting to get a little esoteric.

So considering only the issue described in isolation, and constrained by the only tools available being bash, then:

echo "grant all on database.* to 'user'@'localhost' identified by '$PW';" | mysql

is slightly better (by default, echo is a bash builtin and hence does not start a new process with a command line).


How many certificates can a CA issue before its secret key is renewed?

I don't think there's any technical limit, in terms of x509 standard as published by ISO/IEC/ITU-T (I don't have a copy of ISO 9594-8 to confirm this, if anyone does, can you please check this?). However, according to RFC 5280: "serial number MUST be a positive integer" and "Conforming CAs MUST NOT use serialNumber values longer than 20 octets", so a single CA certificate can issue 2159-1 direct descendant certificates with unique serial numbers conforming to RFC 5280.

In practice, each CA often have implementation limits on their infrastructure that further limits what they'll actually be able to generate. However, non-CA implementations may treat the serial number field as a BLOB, so they would be able to handle even oversized or incorrectly encoded serial numbers.

In terms of managing business risks, it is indeed wise for a CA to limit the number of certificates that a single root or intermediate certificates can issue. This is so that if, for any reasons, they have to revoke the root or intermediate certificate, they would only need to reissue a smaller number of certificates rather than what happened to Symantec, in which a problem with one of its subsidiaries causes the certificates for their entire user base to be revoked, as there's no way for browsers to distinguish between certificates issues by the problematic subsidiaries compared to the certificates issued by compliant subsidiaries.


Received a set of SMS/MMS containing 2 photos, a voice message, and a text "I need help" with Google Maps link from a known contact. Is it spam?

This does not seem to be a virus. It is a panic function in some android phones, that allows to send these messages in case you are kidnapped or otherwise in danger by pressing the power button 3 times. She must have activated it accidentally.

More info here and here.


Encrypt and Authenticate localhost-traffic?

You need encryption to deter passive attackers (evil people who spy on the line and try to work out the data contents), and integrity (and its sibling authentication) to block active attackers who alter the data while in transit. SSL provides both. However, this makes sense only in contexts where attackers can actually spy on or alter data in transit. For two process on the same machine, communicating through the "localhost" network, attackers who can do that have, usually, "already won".

Details may differ depending on the OS. However, your security will normally depend on the OS, not on encryption. Consider, for instance, a Unix system with multiple users. If your two processes talk to each other, then processes from other users cannot peek into the data exchanges (unless the attacker is root, and then he can do anything); however, they may try impersonation: at some point, one of your components must connect to the other, and the rendez-vous point for TCP sockets is a port number. An attacker who can run his own code (as an ordinary user) on the machine may maintain a fake server which will receive the connection request in lieu of the intended component. To protect against that, the client would have to make sure that it talks to the expected server (and vice versa): this can be done with SSL, but better solutions exist (in this case, using Unix-domain sockets with a path protected by system access rights and/or getpeereid()).

If, in your case, the local machine is assumed to be "clean" (no hostile code runs on the machine, under any identity), then connections to localhost are safe and there is no need for any extra protection. If potentially hostile but unprivileged code may run on the machine (that's the "shared multi-user machine" model, as was typical of Unix systems in the late 1980s), then you should use the OS features to make sure that connections are indeed conveyed to the right process (i.e. to a process running on the expected identity). SSL would be overkill.


Why can SSH negotiatie two different encryption and authentication algorithms?

Why was this allowed? Has there been a use-case for this odd behaviour back in 2006 when the RFC was published?

It is mentioned in the RFC 4521

4.3.  Policy Issues
The protocol allows full negotiation of encryption, integrity, key
exchange, compression, and public key algorithms and formats.
Encryption, integrity, public key, and compression algorithms can be
different for each direction.
The following policy issues SHOULD be addressed in the configuration
mechanisms of each implementation:

Encryption, integrity, and compression algorithms, separately for
each direction.  The policy MUST specify which is the preferred
algorithm (e.g., the first algorithm listed in each category).

I haven't seen an attack to consider the separation. The RFC only uses the SHOULD. This is high probably a conservative approach so that in a future attack instead of updating the standard in a bulk, replacing the SHOULD to MUST will suffice.

Is there any SSH server out there which actually implements this? OpenSSH appears not to do so.

I've looked at some of them and couldn't see one.