What are some signs that a certain degree in information security will be a quality one?

I have to say, reading the program materials, I'm not surprised.

As you say, the IT security field is very broad - and programming is only a very thin slice of it.  If you love programming, and are looking for it to be the center point of your education and your work, then I'd offer the idea that what you're really looking for are courses in Software Security - and I have yet to see many (or any) cirriculums using this as a center point.

Things to think about when looking for advanced education and working in IT Security...

What do you want the education to do for you?

IT security is still such a new field that it will be a long time before anyone really knows what a "classic" IT security professional is capable of.  It will be even longer until there are jobs that require an IT Security degree as a baseline.  I'd bet money that over the next 10 years, the majority of IT Security professionals are NOT people who have degrees or advanced degrees in anything bearing the title "security" - the field is still too new and too diverse.

So - the goal returns to being - what do you want from the degree?  An IT security degree as the programs I've seen are currently designed will help get you in touch with some of the current best practices and the business tradeoffs in the industry.  But if you want to be a technical whiz at any particular discipline (programming, networking, computer OSes, management) - then consider a program in that discipline.

What IS an IT security degree?

I expect this answer to be extremely dated in the next few years, but worth the attempt...

It's currently separating itself from any specific discipline which contributes to IT Security, in favor of creating an overall perspective that goes across these disciplines and lets students take a broad perspective to:

Identifying and mitigating risk
Making IT decisions that align security with business value
See the gaps in security that occur across disciplines
Align various experts from various disciplines to creating a secure solution that actually works.
Protect the company from a legal standpoint - knowing enough about the law and forensics to make sure that the company operates legally, and that should prosecution of an attacker be necessary, the data provided by techology can be used as evidence

So in any program these days, I'd expect to see a minimal bit of:

Programming - both hacking and secure software development
Operating system security
Network Security
Web app security (yes, some programming but also the application layer network stuff)
Physical security
Social engineering/human policy

With that diverse of a topic set, I'm not surpised that programming (or any single discipline) is only taking a small part of the cirriculum.

The hiring market today

I leap to this mostly because the #1 reason people pursue education is to get a job.  The key to getting a job is to have the skills that people will pay you for.

Since there really is no predent yet, there's not a single job that recruits exclusively for this type of degree.  Key areas that are looking for heavy security knowledge include:

Pen tests - probably the most "glamorous" field - the one everyone thinks of - testing a secure system for cracks and helping to provide input to fixing weaknesses - takes some programming, but as important is a detailed knowledge about what you are trying to break into - products, protocols and human weaknesses.
Audit - reviewing (not pen testing) systems for compliance with security regulations.
Operations - running and making day to day decisions about systems with a high degree of security risk - more likely to require superior debugging skills and judgement than programming knowledge.
IT security implementation - upgrading, and creating new components for secure systems
Risk management - decisions and strategy about the risk of the current state of the system and the risk of making suggested changes to it.

Only a fraction of these jobs currently require hacking expertise or serious programming skills.  Most require some depth of knowledge about key security controls and an ability to learn and review security controls in light of the capabilities of hackers.

Evolution in progress

Security related cirriculums are very much in transition.  Professional groups I work with now are actively engaged in revising and refining these programs - they are very new and still very much in transition.  The trick I see as a hiring manager is that there's a rock and a hard place right now - the key jobs in security that are very hard to fill take serious technical expertise, great communication skills, and good judgement.  The way these roles are filled right now is with people who are usually 10+ years into their careers - they've gained technical depth in key areas through previous work, they've survived some serious challenges that gave them good judgement and they've spent enough time communicating to have gotten better at it.

Ideally, those of us in the industry will find ways to leverage new college grads to fill in some of this work and leverage our experienced folks as guides and mentors - like other technology disciplines.  The trick is - there's no one sized fits all program yet.  Risk, cost, the nexus of technology and people - that's more or less transferable job to job.  But the details that each roll needs has typically been so company specific that it's hard to fill.

Computer & Network Security - specifically

This particular course is branded as Computer and Network Security, specifically, which is - IMO - rather enticing.  I've seen IT Security, and CyberSecurity and the open ended nature of these titles always makes me worry.  At least computer & network security suggests a program centering around ... well... computers and networks!

Taking the program in smaller detail, and going back to my main points:

Identifying and mitigating risk - hard to tell in this cirriculum - there's a principles and practices - but I'd have to read a description to see if they agree with me on risk mitigation as a "best practice".
Making IT decisions that align security with business value - maybe - there's some intro economics here, but one wonders how close to IT it really gets...
See the gaps in security that occur across disciplines - hopefully - but this is really hard to teach
Align various experts from various disciplines - yep - the various SEC courses are doing a decent job - some OS (LINUX and Windows), some networking (there's a 101 telecom sounding course, and also one on networking security controls)
Protect the company from a legal standpoint - nice - the CRJ and LES courses are pretty enticing - assuming the course is of high quality, the philosophy course on ethis is nice, too.

If I were interviewing a candidate and saw this degree, the first step would be to do what I'm doing now.  I'd also:

scope out other graduates - what fields are they working in?  This looks forensic heavy - are candidates working primarily law enforcement?
Interview for content - certainly the basics look good - can the candidate really configure the security controls I'll need him to configure?  How hands on was any of this work (not programming - staging, fixing and installing computer systems and network gear)
look for project work focusing on interdisciplinary collaboration - if you can't work with people who think differently, you won't work in most security jobs.

As a graduate - I'd have one more question -- how many of your professors are working in the field?  The field is growing and changing rapidly - if your profs aren't getting in and doing hands on work, then you're getting a theory based education and you may have to unlearn much of what you've learned when you get to a job.  A real key in this area is having the opportunity to work with people who have knowledge of the industry and whose theories have been proven in practice.


sql injection: single quote vs double quote

In PHP variables will not expanded inside single quotes (see http://php.net/manual/en/language.types.string.php) so that when the whole string is included in single quotes it will not be affected by your SQLi example.  That means the following statement would be sent to the SQL server:

select * from admin where user_name="$user" and password="$pass"

This is probably not what you would expect, because you expected that the variables get expanded, i.e. something like this:

select * from admin where user_name="some-user-name" and password="some-password"

To make the variables expand in the string you must use double quotes around the string in PHP, like you did in your other example. But then you are vulnerable to SQLi like you noticed.

For information on how to properly protect against SQLi see http://bobby-tables.com/.


Secure implementations of G2/G3/G4 cellular technology

The situation is worse than that.  Various political forces led to GSM being weaker than it should have been, and as is often the case with proprietary technologies, the security engineering of GSM was flawed.  Both the A5/1 and A5/2 stream ciphers have been broken, and there are weaknesses in the latest, KASUMI (aka A5/3), despite indications that they knew better than that.  So it seems that any compliant implementation puts users at risk.  This much is clear from  GSM - Wikipedia


Is there a need to have XSS filters when I'm saving data as XML?

I'd rather use JSON instead of XML. It is easier to understand how the parser works and so the security risks are much lower. For example you have to turn off loading external entities with libxml_disable_entity_loader(true) if you don't want an XXE attack, and so on.

The other part of the question is the generation of HTML, SVG etc. in the browser. For example with innerHTML = "..." it is easy to inject javascript. With data tags it is possible to inject javascript into firefox, so filtering only script tags is not enough... You have to use always DOM functions like createTextNode() instead of innerHTML. You don't need a server side storage to inject javascript. Displaying cookie or query parameters using javascript is more than enough. On server side you have to use DOM functions either, I am uncertain how secure they really are, but they are much better than concatenating strings... Ofc. you have to filter against HTML elements, etc... But if you need a rich text editor then you have a big problem...

I think one layer of security is never enough, and in this case it is certainly not enough. This is because HTML parsers are very complex piece of technology, and most developer (including me) only understands the basics of them. What you really need in this case are some security headers, like Content-Security-Policy. So the injected script won't be able to communicate with the attacker domain. (Ofc. this does not work in old browsers like ie6.)


Preventing a spoofing man in the middle attack?

A router misbehaving and trying to act as a fake server with regards to the client, and a fake client with regards to the true server, forwarding data in both directions, is the exact definition of a man-in-the-middle attack. Apart from routers (which act at the IP level), classic practical methods for MitM include:

hijacking a HTTP proxy
subverting the DNS so that the client uses the wrong IP
running a rogue WiFi access point

(This list is in no way exhaustive.)

To defeat these attacks, we use server authentication which, in the case of SSL Web sites (like https://www.paypal.com) uses X.509 certificates. When the client (a Web browser) connects to the Paypal server, it explicitly requires a "secure connection" (because the URL begins by https://, not http://) and will reject the server unless the server uses a certificate which:

is issued by one of the root CA that the browser trusts a priori (the Verisign/Entrust/Thawte/whatever that were included by the browser vendor), and:
contains the expected server name in it (www.paypal.com, as specified in the URL).

On mismatch, the browser will warn the user in a spectacular way. The MitM will be successful only if one of the CA goofs up (i.e. the CA issues a certificate containing www.paypal.com to somebody who is not at all the owner of the paypal.com domain), or the user goofs up (by using a URL which says www.paypal.com.evilhacker.com, or by not paying heed to the scary warning displayed by his browser), or the user machine is already compromised (e.g. through some malware which installed a rogue root CA).

Generally speaking, SSL has been designed so that security is maintained independently of the transport mechanisms. SSL security does not rely on routers behaving "honestly". SSL assumes that routers are all hostile.


Are repeated multi-factor authentication codes a problem

This is an intended functionality. There is no point in sending separate 2FA code every time within, for example, 5 minutes if it hasn't been used.

From a security perspective this isn't a problem, for if your 2FA method is compromised it won't matter if you send different or the same code. The main thing is for the pin code to not be easily guessable within the time frame it is repeated.


What is the best way to store a password on a system/server?

It tends to be OS and application specific, but you're looking for a keystore.  Depending on your programming language there may already be a suitable keystore.

There are also OS-specific keystores.   For example, on Linux you have keyctl (see the man page for detail) that stores secrets in the kernel.  These obviously don't persist across a reboot so you'll want to load them from an encrypted file or another host across an encrypted (and authenticated) connection shortly after boot.

(I do exactly this for storing email passwords on a Linux machine.  I load the passwords into the persistent keyring shortly after the machine boots.   With some effort, I could automate this and have the credentials securely pushed from a different machine that didn't reboot.)


How can I find webpages with webapps using a specific framework?

There are many ways you can get an idea what technology a particular site uses. Among them are:

observing file extensions in URLs
technologies mentioned in job postings
tech blog articles
company's open-source work
header leaks

So build a list of candidate sites and then go inspect them.


Assuming you don't mean "the connection is TLS-based" as in "the VPN service is TLS-based": No.

TLS is end-to-end protection, established from your client (browser) to the address (typically a web server or load balancer, sometimes a proxy or reverse proxy server) that you're trying to reach. The server is located by IP address and authenticated by ensuring it has a trusted TLS certificate for that service, and the corresponding private key. None of the switches, routers, or other devices - including VPN servers - along the route will terminate the TLS until it reaches the destination host (although that host might terminate TLS and then send another request, possibly a plain-text one, beyond that; this is pretty common for load balancers serving a cluster of servers).

VPNs are transparent tunnels; the TCP connection that your browser makes to the server you want to use TLS with will be wrapped inside the VPN tunnel between your device and your VPN server, and then transparently forwarded to its actual destination by the VPN server; responses will be tunneled back to you. VPN servers can monitor and even tamper with traffic flowing through them, but that's where the end-to-end protection of TLS comes into play: assuming that your VPN server does not have the target host's private key (or a fraudulent but trusted certificate for that host), the VPN server can neither decrypt nor (usefully) change the TLS traffic, save by just closing the connection.

Of course, some VPNs do use TLS for the VPN connection itself. Those TLS connections obviously end at the VPN server (because your device established a TLS connection with the VPN server, not with something beyond it, when it connected to the VPN). However, even in that case, if you then make a TLS connection through the VPN to some other server, then your "some other server" TLS connection will be tunneled through your VPN TLS connection. In that case, tunneled TLS connection will still be the same TLS connection after being forwarded by the VPN server, and the VPN server will still have no idea what it says.


How Do antiviruses decide whether a file is to be quarantined or not?

What if the file is a system file?

Before releasing the signatures to public, the antivirus vendors would test them on different machines with different OS and programs installed. If the signatures contain a hash which detect a system file, and is a false-positive, they'll fix the signatures and re-test them and then release to public.

  Or if the files are EXE/DLLs required by system to work normally?

The reason a detected file is quarantined is that if it is a false-positive, it can be restored to where it was. Almost all the antivirus vendors provide a feature to users to report potential false-positives. If it is found to be a legitimate error, they would fix it in the next update, and that file won't be reported in the next iteration of updates.

  How does an antivirus suite decide whether a file is safe to be quarantined?

If the suite detects it to be malicious by any means(signature hash, heuristic, etc.), it quarantines the file. Now the decision is left to the user if he/she wants to revert it back or not.


How does the mobile security technology APNS and 3LM work?

APNS is a way of pushing updates from third party application servers to the iOS devices. It has nothing to do with the security. Apple believes that it saves battery life having push technology over traditional background processes(pull technology).

3LM is a MDM (Mobile Device Management) software. With the emergence of Bring Your Own Device (BYOD) initiative in the corporate world, the employee's phones and tablets must be protected by malware. These technologies maintain a whitelist approach (sometimes also a blacklist) meaning only the above mentioned softwares can be installed by the employee from the Android Market.

In some worst cases, corporation will have their own Market or AppStore and employees can download apps available on those appStore.

p.s: You cannnot play Angry Birds :(


CSRF double submit cookie pattern questions

Starting with the questions:

Scripts can send CSRF requests (via XMLHttpRequest and fetch), not just forms and implicit GETs of page resources. However, there are very strong limits on what types of requests a script can send cross-origin. In particular, you can't send custom headers cross-origin at all unless the target origin (your site) sends a suitable response to a CORS pre-flight request (a special OPTIONS requests that the browser automatically sends before making any cross-origin request that an HTML form couldn't make). The response would need to specifically allow the custom header(s), along with allowing to source origin and, if relevant, user credentials (generally cookies). Thus, unless you've gone well out of your way to allow unwise things in CORS, simply requiring a custom header at all is proof against CSRF. You don't need to worry about the header value; it could even be the same for every user.
With that said, though, no. There isn't any way to get the value of a cookie into a header in a way that wouldn't be readable to a same-origin script (such as one injected via XSS). You could make the cookie HttpOnly and then either include the value somewhere in the response body or make it available via an API, but a script running in the user's browser on your origin can read such values.

Unless the attacker has a script running on your domain, or is able to intercept plain-text traffic between your server and the user, the attacker won't even be able to read non-HttpOnly cookies. Even if you make CORS tear as large a hole as possible in the Same-Origin Policy, there's just no API for scripts to read cross-origin cookies. That includes cross-origin cookies in requests originating from the script's origin.
With that said, I'm not sure why you think configuring CORS is relevant to anything an HTML form does. For "simple" requests - the kinds a form can send - CORS has no impact at all except on whether the sending origin can read the response, and forms can't do that anyhow (except in the sense that navigating the page is "reading the response", but it changes origins when doing navigating). If you didn't mean using an HTML form submission, there's no need to trick a user into filling out anything (actually, there isn't anyway, forms can be pre-filled or filled using JS and submitted automatically using JS, all with no user interaction).

The hidden form field is needed if, and only if, you're relying on an anti-CSRF secret token that is otherwise only sent in a cookie. If the token is sent in a header (or if you're just relying on the existence of the header, see #1), you're fine. If you're instead relying on the SameSite attribute on the cookie (don't do this yet, some very few people still use outdated browsers), then - much like the header - it won't be sent on cross-site requests anyhow so no need to compare the value to anything. Of course, you can send the value in both header and body (as well as cookie), and just check whichever is expected for the particular endpoint; this is sometimes done for sites that need to be usable without JS (precludes custom headers) or that are based on legacy web frameworks that relied on HTML form submissions instead of submitting requests via script.
There still isn't any way to do this without XSS being able to read the value.

Signing the token with a secret generally implies a server-wide (or even cluster-wide) secret, so you'd store it the same as any other such value (possibly in an environment variable, file outside the webroot including possibly a .env, database field, etc.). There's no point in using double-submit cookies at all if you're going to require a per-user secret to verify them; the whole point of this pattern is to avoid storing any per-session or per-user data that causes a bunch of extra DB hits / cache coherency issues. If you don't mind storing per-session state and looking it up on each state-changing request, generate a random token when the session is created, store it in the DB, and require it be present in request bodies; no need for anti-CSRF cookies at all in that case (their advantage is that no server state is needed).

In general, you don't need to worry about your CSRF protection holding up in the face of XSS. XSS pretty strictly dominates CSRF in terms of what it can do; if the attacker is able to pull off an XSS attack, CSRF protections are pretty meaningless (some, like SameSite on cookies, might present a bit of a speed bump, but even then I wouldn't count on it being sufficient). Remember, once a malicious script is injected into a page running on an origin (which is what XSS is), any requests it forges aren't actually cross-site any more.
Binding anti-CSRF tokens (in a cookie or otherwise) to a user just means that the token value depends on something known about the user and not known by an attacker. A simple example is to use, as an anti-CSRF token, the hash of the user's session token (assuming it doesn't change too frequently). Since the attacker doesn't know the session token - if they did, they could just hijack the session directly, no need for CSRF or XSS - they can neither guess the actual anti-CSRF value nor plant a forged anti-CSRF cookie on the victim. Another upside if this approach is that you don't need a separate cookie for anti-CSRF; the session cookie becomes, effectively, also the anti-CSRF cookie (hash it and see if the result matches the token in the request body).
Cookie prefixes are a way to avoid the risk of cookie-planting attacks, by specifying that cookies with certain names (those that start __Host- or __Secure- can only be set under certain conditions. This is necessary because, historically, cookies could be clobbered by other cookies from less-secure sources (e.g. HTTPS-created cookies from HTTP responses, specific-domain cookies from a subdomain or parent domain). Additionally, since cookie metadata (flags, origin, etc.) is not transmitted in browser requests, the server couldn't tell the difference between (in this case) the anti-CSRF double-submit cookie that it created, and one that an attacker created (assuming the attacker had some vector for planting cookies). However, cookie names are transmitted in browser requests, so a few name prefixes were carved out for special treatment that blocks cookie planting attacks. The idea is, you'd rename your cookies from, e.g. sessionid and anticsrf to __Host-sessionid and __Host-anticsrf. You have to change the name of the cookie that your check for in the request, too - the browser includes the prefixes when sending it back to the server - but the idea is that if those prefixed cookies are present, you can be sure the cookies weren't set by a different (sub/parent) domain or an insecure connection. Of course, this feature is new and not yet universally adapted, so it's not entirely safe to rely on it today (though it doesn't hurt to use it anyhow).

Honestly, at the end of the day, I really can't recommend anybody implement double-submit cookies today. Much like X-Frame-Options and then CSP made framebusting JS obsolete, and CORS made JSONP obsolete, double-submit cookies were a quick-and-dirty hack of a solution that has been superseded by better options.

Use script-initiated requests and add something to make them non-simple (couldn't be sent via HTML form submission), such as:

Any custom header
A verb other than GET, POST, or HEAD
A content type other than text/plain, application/x-www-form-urlencoded, or multipart/form-data (a common choice is application/json or sometimes application/xml)
A custom value in one of the standard headers that aren't a "CORS-safelisted request header", such as setting a custom Authorization header containing a bearer token (in which case you can avoid security-sensitive cookies altogether).

If you can't / don't want to do that, require that the request body (and thus, realistically, the HTML forms) contain a hidden anti-CSRF token that is the hash digest (or possibly HMAC signature generated using a server-secret key, though that adds little real benefit) of the session token.

If you're really paranoid about timing attacks, hash the session token once to generate the hidden anti-CSRF token, and hash it twice (and the token from the request body once) before comparing.

Use SameSite=Lax flags on your security-relevant cookies for any site that doesn't need to support authenticated calls across sites. Use SameSite=Strict for cookies on sites where the site doesn't even need to support top-level navigation from an external domain directly into an authenticated request.

While SameSite support isn't 100% yet, it's getting close, and it doesn't hurt anything to use it.
In fact, newer browsers are starting to treat cookies as Lax SameSite by default, now, so it really doesn't hurt anything to use that. You'd need to explicitly mark the cookies SameSite=None to get them to send on cross-site requests.
EDIT: As another contributor pointed out, "Sites" (as relevant for SameSite) are broader (and just harder to identify) than "origins". SameSite acts on sites, not origins, and might therefore allow cookies in some situations where you'd expect it not to. https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/


Is it possible to establish a secure TLS connection using only client certificate?

From RFC 5246 (TLS 1.2) section 7.4.4 "Certificate Request":

  It is a fatal handshake_failure alert for an anonymous server
     to request client authentication.

It it is not clear in your case if the server is anonymous. But, you specify that the server does not provide a server certificate and you don't say anything about other forms of authentication, like PSK. This suggests that the server in your use case is not authenticated which means it cannot request a client certificate.

But, based on your question you don't actually need a client-certificate-only TLS handshake at all. What you need instead is a TCP connection from A to B followed by a TLS handshake from B to A. In this case A has a role of a TLS server with a certificate known to B. This kind of setup is possible since all the TLS handshake needs is an established underlying (TCP) connection. It does not matter who initiated the TCP connection.


Can someone explain what exactly is accomplished by generation of DH parameters?

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and eventually acquires the private key, he can use that to decrypt the session key from SSL exchange, and then use that to decrypt the whole session. So that's not perfect forward secrecy.

The key here to Perfect Forward Secrecy is the Diffie-Hellman key exchange. DH is a very cool algorithm for generating a shared key between two parties such that an observer who sees everything -- the whole exchange between the two parties in the clear -- cannot derive the key just from what is sent over the wire. The derived secret key is used one time, never stored, never transmitted, and can never be drived ever again by anyone. In other words, perfect forward secrecy.

DH alone can't protect you because it's trivial to play man-in-the-middle as there's no identity and no authentication. So you can continue to use RSA for the authentication and just use Diffie-Hellman to generate the session key. That's DHE-RSA-*, so for example: DHE-RSA-AES128-SHA1 is a cipher spec that uses Diffie-Hellman to generate the key, RSA for authentication, AES-128 for encryption, and SHA1 for digests.

But Diffie-Hellman requires some set-up parameters to begin with. These aren't secret and can be reused; plus they take several seconds to generate. But they should be "clean", generated by you so you know they're not provided by an attacker. The dhparam step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.

Some recent bit of research showed that while "breaking" a DH exchange (that is, deriving the key from the traffic) is difficult, a fair amount of that difficult work can be done ahead of time simply based on the primes. This means that if the same DH primes are used everywhere, those become a  "prime" target for well-funded agencies to run their calculations against. This suggests that there is some amount of increased safety to be had in generating your own primes (rather than relying on those that come with your software), and perhaps in re-generating those primes periodically.

An interesting bit is that Elliptic curve Diffie–Hellman is  a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating.

See also:

What is ECDHE-RSA?
SSL/TLS & Perfect Forward Secrecy

With respect to BEAST
The BEAST attack relies of some artifacts of the block chaining method used with AES on older versions of SSL. Newer versions of SSL do things right, so no worries there. RC4 is not a block cipher, so there is no block chaining. The BEAST attack is so absurdly difficult to pull off that its real-world implications are decidedly nonexistent. In fact, RC4 has some weaknesses of its own, especially when when abused the way the BEAST attack would have to do. So you may not actually be getting any better security.

Certainly forcing TLS 1.2 would solve all your theoretical security problems, while at the same time preventing many visitors from actually connecting. Not entirely unlike using ECDHE.


Why is information/cyber security important to the average internet user?

Why do you lock your house? Why do you not walk down dark side streets at night in a city's downtown? Why do you not start bar fights? Why practice safe sex? Because of the risk of loss.

Security is about protection. Now that most of one's life is held and transacted online, one needs to protect oneself from loss there, just as in the physical world.

You might not care about loss online (this is becoming a more common perception), but that does not diminish the importance of security online. I would point out that those I have talked to who do not care about loss online are not aware of what they could lose. Similar to the lack of knowledge of what could happen when one does not practice safe sex.


Does mounting a LUKS partition authenticate it?

can they create a new encryption key and encrypt it so that the original passphrases can decrypt it?

I don't see how that would be possible.

As you already  know, Luks works by generating a random "master" key which is stored in the Luks header and used to encrypt the contents of the disk. Actually there are 8 key slots which reference encrypted copies of the master key. If you open a Luks partition, you provide a passphrase to decrypt one of the encrypted master copies, which will then be used to decrypt the contents of the container.

Encrypting and decrypting the master key is done using symmetric encryption. So if someone wanted to create his own Luks partition which accepted the same passphrase as yours, he'd need to know at least one of your passphrases so that when you entered your passphrase on the fake luks container, the passphrase would be able to correctly decrypt the master key with which the data in the container was encrypted.

The small print

  Can I be sure that the (unencrypted) contents of my LUKS volume were not tampered with if it accepts my passhprase on an otherwise trusted system?

No. Not knowing the passphrase does not protect the Luks container from tampering. An attacker can always overwrite any part of the container with any data he chooses; it's just that usually, when you open the container and decrypt whatever was changed, it will decrypt to random nonsense and possibly break the file system, which will then notify you that the file system got corrupted.  However, it might take a while before you access a section of the filesystem that was tampered with; until you access it or run a filesystem integrity check, you won't notice any tampering was done.

That's probably not what you're worried about, but how about this scenario:

You have a Luks partition. You're very diligent, so you back it up onto another hard drive using dd (e.g. making a byte-by-byte copy of the partition).

The attacker gets hold of your backup hard disk. What he can do now is compare the two disks, the new one and the old one, and figure out there are changes. When he finds a section that looks promising to him, he can take the old section from the backup drive and copy it to the exact same spot on the productive luks partition.

Sometimes, this will fail and also result in a corrupted filesystem. However, in some cases it will work, e.g. it will change some file or directory contents back to what they were when you took the backup, without giving you any warning that the Luks partition was modified by someone else. This attack is more likely to work on older, non-journaling filesystems and it will most likely always fail on copy-on-write filesystems such as btrfs.

So, to sum up, making exact byte-level backups of a Luks partition might enable an attacker to transparently revert any change made on the productive partition to the version in the backup.

If that's a problem, you can avoid it by creating a fresh luks partition on the backup medium and copying the plaintext filesystem data inside the container instead of cloning the Luks container itself.

Making your Luks container tamperproof

In order to make your Luks container tamperproof, you can build a hash sum over it whenever you're done using it and close it. You store this hash sum somewhere safe. Before you open the container the next time, you again build the hash sum and compare it to your stored one. If they match, nobody tampered with it.

The problem with this solution is that file systems are usually very large and building a hash over the whole filesystem data can take hours or days.


OpenVPN Encryption Algorithm Used For Control Channel Encryption

First: don't disable --auth.  --auth controls the authentication mechanism for the data channel, while --tls-crypt is for the control channel (though, and this is slightly confusing, --auth also controls the auth algorithm used by --tls-auth).

--tls-crypt uses fixed crypto methods, which are HMAC-SHA256 for authentication and AES-256-CTR for encryption.  So yes, as the man page says, --tls-crypt offers an extra layer of both encryption and authentication for the control channel.  The algorithms are not mentioned in the man page, but printed at --verb 3 log level by openvpn op startup:

Sat May 12 22:07:42 2018 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat May 12 22:07:42 2018 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat May 12 22:07:42 2018 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat May 12 22:07:42 2018 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

For more information, you could read the commit message of the commit that introduced tls-crypt (https://github.com/OpenVPN/openvpn/commit/c6e24fa3), or the in-code documentation (https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/tls_crypt.h, or the generated doxygen available on https://build.openvpn.net/doxygen/html/group__tls__crypt.html).


There are numerous things that you could do, depending on whether the host is permanent or if it's under development and might be moved, etc. One way some people store this information during development is simply putting them into environment variables that the application reads. Yes, other applications can potentially read these, but I don't think it's likely for dumb malware to be able to abuse them.

Another solution is to just pass the creds in through command line arguments. This is potentially more work, but other applications and users won't be able to read this as easily (they can of course look through your command line history), and if you decide that it just isn't worth the effort later, you could write a script to run the application with the hard coded creds.

Another idea based off this answer is to have the secret stored on some external hardware that the software could read from. If you're really serious, you could put the secret in an encrypted file that would require a key file or a Yubikey to decrypt. The application would then just read from this file. Obviously, file permissions need to be properly set here so that only the user running the application can read this file.

You could possibly encrypt the secret and store this inside the application, and provide a key through the command line arguments to decrypt it in memory. Whether this is any better than the other solutions is debatable. It all depends on what your needs are and what you're trying to protect the credentials from.


Should I update my SHA-1 certificates? If so, how?

As a user/client,  you can revoke a certificate   only if it contains the same subject name as the certificate presented for authentication. You can do that  using the revocation form provided in the end-entities page. Otherwise only if you are a CA administrator or a Certificate Manager you can do it by yourself.

Implement Role-Based Administration:

CA administrator: Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager:Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.

Your CA can reissue your certificate with SHA-2 signature because, as mentioned in your link, SHA-1's use on the Internet has been deprecated since 2011 and:

  HTTPS sites whose certificate chains use SHA-1 and are valid past 1
  January 2017 will no longer appear to be fully trustworthy in Chrome’s
  user interface.


How to determine if software on many client machines is up to date?

There are several classes of tools that can do this.

You may want to look at using a vulnerability scanner that can run authenticated scans where it logs in and can scan the local filesystems & configurations rather than just scanning the services listening on the IP addresses on the network.

Continuous Integration and Continuous Deployment (CI/CD) tools can gather most of the same information but also help you with making the updates to these systems.

You may find that the best solution for your environment is to use multiple types of tools too.


Default Encryption - A Panacea or Placebo

Is it accurate to say that default decryption is a placebo?

I assume you mean 'default encryption'. No, it is not a placebo. Of course it all depends on how it's actually implemented. I have read your post, and I'd like to point out that James Comey's example

  US-DoJ-FBI Director James Comey (pictured below) has been criticized
  for his warnings of 'encryption by default' with Apple devices and
  Google communications. He has used a hypothetical situation of a young
  girl being kidnapped, and how encryption by default would disallow and
  render impossible the ability to geo-locate the missing child if her
  device is encrypted.

is seriously flawed. In his example we do not care whether the child's telephone is encrypted or not. What we want is a control backdoor into its GPS location service. This is completely orthogonal to the encryption thing:

we can have a service that queries the GPS chip and sends the results to whoever sends a SMS containing the words "Squeamish Ossifrage", whether the phone data are encrypted or not.
if we don't have a service allowing remote access to the phone, being able to read the data it contains, or that it stores in the cloud, is completely worthless. Unless mr. Comey is thinking that a phone might continuously store an encrypted GPS log on the cloud, which some services may well do but is not required by his own use case.

The power of locating/decrypting a phone can be easily escrowed to the child's parents, who can use it or empower the police if and when they see fit.

Can all encryption be cracked? It depends. Given omniscience and/or an infinite amount of time? Probably. In a finite amount of time and with negligible costs? No way.

  How difficult would it be for the FBI to crack Apple's encryption algorithms for iPhones?

I'm not familiar with that algorithm. But let's suppose Apple uses 256-bit AES, implements it properly and does not install any backdoors. A reasonable estimate of FBI difficulty in cracking a two-stage passphrase encryption (i.e. data is encrypted using a random key, itself encrypted in the device using the user's passphrase, not directly using the user's passphrase) is in the neighbourhood of "pretty damn impossible". The best prospect so far, Murphy-Robshaw linearization, knocks off about eighteen zeroes from the number of iterations required. About sixty-seven remain.

There are "suspicions" that some encryption algorithms are flawed by design to allow NSA (or whatever) to break the encryption. But that does not mean that every encryption can be cracked in practice - it just means that it can be comparatively cheaply backdoored.


How do banking software systems securely store account information in database?

They prevent it by using access controls to restrict access to who can change data fields and by implementing auditing to monitor authorized changes.  As you might expect, a database holding banking information is typically fairly restrictive on who can make changes.  They also have transaction logs that may be used to validate account balance changes, where if an account balance change is noticed without a corresponding transfer from another source it is flagged for review.  This as well as the user audit logs maintained work as a means to discourage unauthorized changes as well as identify the source of a change if one was made.

Different countries have different standards, but in the United States of America we have federal and state regulations that subject financial institutions to both internal and external audits of their practices.  Maintaining proper technical and process controls over account management are part of the things these audits investigate.

All of these measures don't make insider fraud impossible, but it makes it much more difficult and likely to be detected.


Based on the information you have provided, i think you should start with having:
 - a good firewall (Sophos is ok, IF it has WAF (web app firewall) as blogs are mostly attacked using app level). But if you dont want to pay, then pFsense is also a good choice, its an all in one firewall.

host it behind cloudflare or incapsula (preferably paid packege having WAF and DDOS prevention in it)
IPS/IDS for detection and prevention of attacks (pFsense has snort for it or suricata)
Network design seems to be ok, so its better to have vLANS for network segregation
Monitoring system (with logging based on any SIEM, like OSSEC)

I think that should be enough for you


Are wedge attacks on EMV cards still viable?

Wedge attack was applicable on DDA cards (Dynamic Data Authentication) which were being superseded by CDA cards (Combined Data Authentication) at the time when vulnerability was disclosed.
The researchers behind the vulnerability proposed a solution to fix DDA cards in his write-up: Defending against wedge attacks in Chip & PIN but there's no track record of which banks globally enforced this solution or even cared to address it.
CDA partially resolved the problem with DDA but it was itself open up to a vulnerability called No PIN attack. The wedge was used even in this attack but the method of exploitation was different than that of DDA as explained in their research paper, Chip and PIN is broken.
Their proposed solution as mentioned in the paper fixes CDA and only Barclays Bank UK PLC is known to fix No PIN attack (52:20).

One possible work-around is for the terminal to parse the IAD, which does include the result of PIN verification. The card can change its CDOL to request that the CVMR be included in the payload to the Generate AC command.

Unless the CVMR is included in the CDOL it may not be integrity protected, so a second man-in-the-middle between terminal and acquirer (perhaps installed with co-operation of a corrupt merchant staff member) could tamper with it too.

EMV Book 4, 12.1.1 - Authorization Request  - Table 9 contains the new data elements specifically created for an ICC transaction. It is added in the book in November 2011, a year after the vulnerability is disclosed. Now the terminal can also send CVMR (Cardholder Verification Method Results, specifies which cardholder verification method the terminal believes was used) optionally with the transaction approval request but unlike IAD (Issuer Application Data), it it is not integrity protected. The issuer then validates CVMR against IAD to ensure both the card and terminal have the same perspective on how the transaction is happened.
A year after the vulnerability is disclosed publicly, a criminal ring was caught performing this attack which the Cambridge researchers believe that the French criminals worked out the attack independently.

The ENS and CEA forensic researchers note that the vulnerabilities used by the French fraud they analyzed have since been fixed—at least in Europe—though they declined to fully detail the new security measures.
The French researchers who investigated the case write in their paper that EMVCo has since created new countermeasures to the vulnerabilities the fraudsters exploited and implemented them both in card readers and in banking networks. They also note that other protections have been added to the system at the network level, which they decline to detail for fear of tipping off criminals.

I doubt all the banks globally have implemented this solution as another decade old vulnerability is again discovered to be lurking around in some banks: Researchers create magstripe versions from EMV and contactless cards: Banking industry loophole reported more than a decade ago still remains open and ripe for exploitation today.
The only reason they are not seeing frauds is because most of them enforce online PIN verification. But as the specification was updated in 2011 and most banks outsource the production of EMV cards, they might be coming with a fix particularly the new ones in countries where EMV is recently mandated.


Possibility of SQL injection by static or predefined values

Situation-1
It's a function. Which means it could be called with different parameters and you cannot foretell whether these will be predefined or not.
Besides, I just don't understand why you're asking at all. Is a prepared statement that hard to use to make you seek a shortcut for a deliberately rare use case?
Then ask how to make a prepared statement easier to use. It's not a rocket science and will make your code as simple as
function fetch($id, $subid){
    $sql = "SELECT * FROM...WHERE id=? AND subid=?";
    return $this->con->run($sql, [$id,$subid])->fetch();
}

so there will be just no reason to avoid a prepared statement.
Situation-2
This is called a "second order SQL injection", and being the very reason to use a prepared statement for any variable, regardless of the source.


I would say, why not just encrypt & sign using GPG as usual... then put this into your steganography program of choice.  That is... unless you want some security by obscurity... but then again, you're already doing some of this by using steganography.

There are many steganography tools available, and many different file formats to choose for embedding your message (ie: png, jpeg, tiff, mp3, avi, mpeg).  A list of steganography tools can be found here.  The size of the message, or how 'heavy' it can be depends highly on what tool you are using, and the size of the carrier file.

You can hide a lot more data in a larger file without it degrading the quality, or becoming noticeable.

For some simple open source steganography tools, perhaps try out OpenStego or StegHide

EDIT: Do note that depending on the context of the message transmission, a certain file type or a large file may indeed be very noticeable.  For example, on a network where small images and HTML pages are predominantly transferred, perhaps a large DVD .vob would stick out like a sore thumb.  The purpose of steganography is to conceal the message so it's completely undetectable.  Context is everything here.


Tamper-resistance

The world of FIPS 140-2 certified cryptographic hardware has a similar requirement at levels 2 and 3

Devices certified to FIPS 140-2 Level 2 are required to "show evidence of tampering", which is usually accomplished by putting stickers similar to the usual "Warranty-void if removed" type stickers over screw holes and seams, but the FIPS 140-2 version of these stickers are serial numbered and like explode ink and change colours when you remove them. They are not fool-proof though and can be removed with a lot of skill and patience.
Devices certified to FIPS 140-2 Level 3 are required to have "strong enclosures and tamper-detection/response circuitry that zeroes all [cryptographic keys] when the removable covers/doors of the [device] are opened."

You tend to see this on high end servers intended for performing cryptography (ie HSMs) which run in the $1,000 - $10,000 USD range. I have never heard of this kind of tamper-evidence / tamper-resistance on consumer devices like HDDs and keyboards, but I suppose it could exist if there's a market for it?

Hardware fingerprinting

Probably well beyond the scope of your question, but it reminds me of the field of study around Physically Unclonable Functions (PUFs) -- they are essentially hardware hash functions in the sense that they will always give the same output to the same input, but their behaviour is very hard to characterize or duplicate. These are usually complex crystals where you measure a laser's optical path, or complex electrical circuits where you measure precise latency and resistance from input pins to output pins. They are mainly used for uniqueness -- each device has a unique fingerprint -- but they also match your question that their signature will change after physical tamepring (I've heard of PUFs being built in to device casings to detect if the seal has been broken, for example).

Now, you're asking if this can be done with arbitrary consumer-grade computer parts, say a Western Digital hard drive.

**Here begins wild speculation:** Whether you can take an existing circuit and characterize its latency and resistance as a PUF, or whether you would need to build a PUF into the circuit I don't know, I'm not enough of a PUF expert. Either way, for this to work, I presume the manufacturer would need to put each device on a very high-precision machine as it comes off the assembly line, publish the results. Then you would need to buy the same testing machine, test your new hard drive, and compare the results to the published results for the serial number of your device. You couldn't build the testing device into the HDD (or even ship it in the same box) because then the attacker could just reprogram that to always display the correct result.

Bottom-line: I have never heard of the kind of tamper-resistance that you're talking about for consumer devices. In theory it's possible, but would probably significantly increase the cost of the device.

A reasonable middle-ground for the amateur tin-foil-hattist is to only buy electronics in-person off the shelf from reputable big-box stores, and never order them online where they will be shipped across the country (and possibly across international borders) with your name on the box.


No this is not considered safe, you do not make any attempt to sanitize the environment you are running in. Which will let the attacker manipulate what gets executed as root by manipulating the environment through various environment variables, from PATH to LD_PRELOAD. Specific vulnerabilities vary, and there is some effort to mitigate in dynamic loader but still you should sanitize environment and ensure you are in control of what gets executed in privilege context ensure only the relevant input is passed and nothing else ensure relevant input is valid.


A website had a breach and isn't telling customers. What can I do?

Because they know about it and are open, when asked, about the problem, it is possible that there is nothing more they are required to do. Various jurisdictions require breach notification, but which jurisdiction applies to this company is beyond the scope of this site.

So, you can check to see if they need to report, and prompt them to do so or to report them to the relevant authority. Or you might find that there is no defined avenue for you to push the company to act.

As always, you could see if a journalist might be interested, but then you're scrambling for someone to take an interest in the problem.


How reliable are device IDs provided by PhoneGap on Android and iOS?

No, UUID can be faked when reporting from a client.  Do not assume it proves anything about the identity of a device and do not assume that it is the same device as the last time you saw it.  If you really need to verify a device, the best bet is to make a certificate that you can store on the device and ask for that certificate when looking at it.

If they are genuinely reporting, they should be universally unique (what the UU stands for) but it is entirely possible for someone to force it to report a non-unique value of their choice in many (if not most) cases.  It can even be done with simple applications available on the app store on Android.


Does the use of JavaScript make ProtonMail insecure?

Note: this question might have been better on the Tor community despite being on-topic here.

Thomas Roth demonstrated that Protonmail was vulnerable to a Cross-site scripting (XSS) attack.

The video (Vimeo) he made shows that at least the mail body was vulnerable to Javascript injection. As soon as the receiver read the mail, the code is executed. Unfortunately, this code can be malicious and can, among other things, deanonymize the user. The FBI showed that it was possible when they seized Freedom Hosting. (Although they exploited a 0-day in Firefox.)

Using the Tor browser with Javascript enabled is risky. Disabling it will reduce the attack surface. The Tor developers are aware of this issue and address it in their FAQ:

  Why is NoScript configured to allow JavaScript by default in Tor Browser? Isn't that unsafe?

  We configure NoScript to allow JavaScript by default in Tor Browser
  because many websites will not work with JavaScript disabled. Most
  users would give up on Tor entirely if a website they want to use
  requires JavaScript, because they would not know how to allow a
  website to use JavaScript (or that enabling JavaScript might make a
  website work).

The Tor browser gives you the opportunity to disable JavaScript (with the NoScript plugin). However, as you may have noticed, Protonmail relies importantly on JavaScript, and disabling it would prevent you from using their service:

  Why do you need JavaScript, Session Storage, and Cookies?

  ProtonMail does encryption and decryption of messages in your web
  browser.

  This ensures that we do not have the ability to independently decrypt
  your messages and thus ensures the security and privacy of your data.
  In order to do encryption and decryption in your web browser, we need
  to use JavaScript for the encryption/decryption and SessionStorage for
  saving your private key(s) locally. ProtonMail also requires cookies
  to be enabled so that we can store your current session information
  and log you into your account.

(Last emphasis is mine.)

Therefore you have to make a choice. Either you decide to trust Protonmail to be secure (even though vulnerabilities have been found); or you walk away and find another solution.


You are overthinking this.

It's possible that an attacker intercepts your connection to Ubuntu servers and redirect your download to a tainted image, but it's a difficult task:

They have to be in a position to be able to MiTM your connection, by standing in the route between you and the Ubuntu Servers
Maybe perform a DNS attack on you to redirect you to another server that they control
If you access Ubuntu using HTTPS, they must strip the HTTPS or provide a valid certificate. Providing a valid certificate requires either a malicious CA issuing the certificate, or presenting a fake certificate AND you allowing it.

After this, if you download the image, you could run a hash check (MD5 or SHA) and verify the image. This is very easy to do, and very, very difficult to taint.

After all, there's lots and lots of programs that can calculate the hash, and the attacker will never be able to compromise every single one out there. You can even calculate this using Javascript in any browser. So it's impossible to an attacker to compromise every hash calculator you could use.


Captive portal (Wifi) remembers me even if I change my MAC address

It may use your WebGL ID (which never changes, unless you reinstall MacOS), or some other variable. Try disabling images, javascript (noscript, scriptsafe). Have a look at
https://amiunique.org/faq . Disable flash and java as well via an appropriate add-on.

The obvious answer is that it's using a cookie, but I assume you've cleared those. Try clearing them pre-connect, and see what cookies are added post-login.

You will learn nothing useful (for solving your problem) by running tcpdump or wireshark. If you run it anyway, do a capture of 2-3 login sequences, and build filters later. I don't use wireshark, so can't help with those, but a tcpdump pcap filter may look like this (for capturing a HTTP captive portal session):
sudo tcpdump -ni en1 -s 4096 host 192.168.1.2 and port 80,
where en1 is your wireless interface and 192.168.1.2 is the IP of the captive portal.


Export GPG key from smartcard and import yubikey

Secret keys cannot be exported from OpenPGP smart cards -- that's the very idea behind them. If you created the key on a computer and imported it to the smart card, use the backup to copy it to the Yubikey.

Otherwise, you'll have to create a new key. Be aware the Yubikey is just another OpenPGP smart card, so if you create the key directly on the Yubikey, you will not be able to export it, again.


IPv6 aside, you have asked: "I have an unused protocol enabled and active on my system without any technical controls around it. Does the situation pose a security risk?" The answer is very short: yes.

Is it a "giant hole"? No, but a hole. Is it a risk? Maybe. But the fact that you cannot quantify the risk means that you should turn it off until you can.

Will there be potential unexpected usability issues? Maybe. But that's not a security question.


Is it possible to use a hijacked but encrypted cookie?

If the victim was using TLS, you either weren't actually able to get the cookie at all - all you would see in that case is a handshake followed by a stream of encrypted traffic (ciphertext), with no way to identify "this part is a cookie" - or you were able to Man-in-the-Middle (MitM) them due to bypassing certificate validation somehow (or having a fraudulent certificate). Or maybe you stole the cookie some other way (a memory leak out of the client or server? XSS on a non-HttpOnly cookie?) and can't actually read the client's network traffic.

In the first case (network attack against client using TLS), even if you somehow identify which bytes of the TLS ciphertext are the cookie, it won't do you any good. You don't know how to decrypt the cookie, and TLS uses different keys for every encrypted session so if you tried just replaying the message the server wouldn't decrypt it to what you thought it as supposed to be.

In the second case (successful MitM on the TLS connection, or no TLS at all), you can definitely reuse the cookie. Same goes for the third case (cookie stolen via side-channel attack). Anything that gives you the cookie in plain text will let you use it, unless the server does some additional filtering (like tying each session to an IP address, and you're not on the same external address as the attacker... but this is very uncommon).


What security concerns should one bear in mind when hacking open-invitation websites?

They definitively can be honeypots. It's very interesting to know how people get in, so you can use the same techniques yourself or to identify them.

Some of these projects are just to learn more about security, but it is definitely plausible that these systems can get abused. After all they are meant to be vulnerable.

I did a similar like school-project where I faked an open sendmail relay and just piped all the incoming emails to a python script that got all the destinations out, generating my own spamlist. I think in the end after about 3 weeks I had close to 300.000 different email addresses.


Is there any solution beside TLS for data-in-transit protection?

Rejecting TLS out of fear an attacker could have stolen a private key is like rejecting medicine out of fear someone could have poisoned it. The downsides far outweigh the risk of not using it.

Why TLS is secure
There are many many angles to answering this, but one that speaks for itself is that everyone is using it. Government agencies are using it, huge tech companies are using it, banks are using it, hospitals are using it, StackExchange is using it too. If TLS would be insecure, don't you think at least someone would decide that it's a bad idea to use it and switch to someone else? The fact that TLS is nearly ubiquitous and recommended everywhere by everyone should tell you that it's a good idea to use it.
Furthermore, TLS is secure, if configured correctly. Version 1.3 makes this a no-brainer, as of the time of this writing, there is no wrong way to configure TLS 1.3. TLS 1.2 is a bit more difficult, since there are some insecure ciphers in TLS 1.2. SOGIS - which also use TLS - have an extensive guide on which ciphers are recommended, and which are still tolerable for legacy usage.
Finally, compromise of the private key leading to insecure communication isn't a flaw with TLS that some other protocol could alleviate - it's a flaw inherent to network communication. If you assume that an attacker has full control over your server, then no matter what protocol you're using, the attack would be able to decrypt any traffic, manipulate any traffic and forge new traffic.
In other words, TLS is not designed to protect against server compromise, and neither TLS nor an alternative to TLS - self-made or otherwise - would protect against that.

Alternatives to TLS
Since the question asks for alternatives to TLS, there is one: DTLS
DTLS is basically TLS, but for UDP. The reason you might want to use DTLS is because your application uses UDP instead of TCP (e.g. a VoIP program), but you still want your datagrams to be encrypted.
DTLS is not more or less secure than TLS, but instead is designed to work with a different underlying layer.


Implementation of security policy using BLP

X and Y can read information from File B and write it to File A. This makes formerly confidential information available to Z.

This violates the "no write-down" rule of Bell–LaPadula:

  The Star-property (read "star"-property) - a subject at a given security level must not write to any object at a lower security level (no write-down)


Are there HIPAA requirements to encrypt our database hosted in AWS

Do we need to encrypt MySQL database in order to keep HIPAA compliance?

Depending on how the entire system is built, it may not be required, but I hope that you do encrypt it.

First you need to identify what PHI (Protected health information) resides in your system and how it may travel through your system. Unless your clients already de-identified or anonymize the data sent to you it is a good assumption that every piece of data you receive is PHI.

A date of service and a patient's first name (or last name) included in a record make that record PHI.

If you believe you can protect the PHI in the database without encryption you need to be able to provide a good security argument that the PHI has other sufficient protections. Even if you can make that argument, the principle of defense in depth encourages additional protection (like encryption) in case your primary protection fails.

You really need to be talking to your company's legal team as HIPPA is a law and failure to comply with HIPAA requirements can result in civil and criminal penalties


Gmail, Yahoo, Hotmail , and so on; How do they check the content of an attached password-protected archived file like Winrar?

They can't.

Encryption is encryption. Email services won't spend time and energy trying to brute force your password, nor do I believe they would create backdoors for the sake of email. If they let you send encrypted archives then they simply don't check the contents.


Difference between pseudorandom generator and pseudorandom function

Pseudorandom generators can be used to feed a pseudorandom function family by repeatedly supplying pseudo-random values to the function. The PRF ensures semantic security, which may be used to stretch keys, initialize vectors or salts. At no point should an efficient algorithm be able to distinguish between a PRF and a random oracle. However this does not fully apply to a PRG, which only guarantees a single value to be pseudorandom. Since the pseudo-random values themselves have no correlation with the PRFs output, in theory it is possible to use a set of PRG as an input.


How valid is this statement "SSL sit between application layer and network layer"

The OSI model which describes networks as a set of rigid layers has never been a good match for TCP/IP networks. It is a remnant of an old terminology war between the world of elegant, abstract, intellectual constructions, and the world of the Internet, aka the network which exists and works.

SSL is built on top of a medium which, in the OSI model, would be "transport" (layer 4): SSL uses a bidirectional channel for untyped bytes; SSL needs that this channel, under non-hostile condition, is reliable (bytes are unaltered and eventually show up at the receiving end in the right order). On the other hand, SSL provides a transport medium (there again, a bidirectional channel for untyped bytes, this times with confidentiality and guaranteed integrity). So, in OSI model terminology, SSL sits between layer 4 and layer 4. Yes, not between two "distinct" layers, but right "in the middle" of a layer.

All of this just shows that the OSI model does not apply to the real world. Why this model is universally taught in all network courses is beyond me.


HMAC - Why not HMAC for password storage?

The point of the salt is to prevent attack cost sharing: if an attacker wants to attack two passwords, then it should be twice as expensive than attacking one password.

With your proposal (your "question 1"), two users with the same password will end up using the same MAC. If an attacker has read access to your database, he can "try" passwords (by recomputing the MAC) and lookup the database for a match. He can then attack all the passwords in parallel, for the cost of attacking one. If your long_string is an hardcoded constant in the application source code, then all installed instances of the application share this constant, and it becomes worthwhile (for the attacker) to precompute a big dictionary of password-to-MAC pairs, also known as "a rainbow table".

With a nonce (your "question 2") you avoid the cost sharing. The nonce is usually known as a "salt". Your long_string and the use of HMAC does not buy you much here (and you are not using HMAC for what it was designed for, by the way, so you are on shaky foundations, cryptographically speaking). Using a salt is a very good idea (well, not using a salt is a very bad idea, at least) but it does only half of the job. You must also have a slow hashing procedure. The point here is that the salt prevents cost sharing, but does not prevent attacking a single password. Attacking a password means trying possible passwords until one matches (that's the "dictionary attack"), and, given the imagination of the average human user, dictionary attacks tend to work: people just love using passwords which can be guessed. The workaround is to use a hashing process which is inherently slow, usually by iterating the hash function a few thousand times. The idea is to make password verification more expensive: having the user wait 1ms instead of 1µs is no hardship (the user will not notice it), but it will also make the dictionary attack 1000 times more expensive. Your long_string may be used for that, provided that it is really long (not 2 kilobytes, rather 20 megabytes).

HMAC may be used instead of a raw hash function to strengthen a password-verification system, but in a different setup. Given a system which checks passwords with salts and iterated hash functions, you can replace the hash function with HMAC, using a secret key K. This prevents offline dictionary attacks as long as you can keep K secret. Keeping a value secret is not easy, but it is still easier to keep a 128-bit K secret than a complete database.


Environment variable and scripting for return-to-libc exploit

Storing the value in the environment is a common (good) practice.

To get the address of the environment variable you can use this C snippet:

(Im assuming you know how to compile it for your system)

/* Author: Jon Erickson */

/* Deps */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Main */
int main(int argc, char *argv[]) {
    char *ptr; /* the needed address will be stored here */

    if(argc < 3) {
        printf("Usage: %s <environment variable> <target program name>\n", argv[0]);
        exit(0);
    }
    ptr = getenv(argv[1]); /* get env var location */
    ptr += (strlen(argv[0]) - strlen(argv[2]))*2; /* adjust for program name */
    printf("%s will be at %p\n", argv[1], ptr); /* Print the result */
}

In your case, lets take that you called it getenv.c, you should issue this command:

./getenv SHELLMINE [Name of the program you are expliting the overflow]

and it will print your needed pointer like:

SHELLMINE will be at [ptr]


Why's the "public key block" different although fingerprint is same for gpg keys

The fingerprint of a key is calculated over the parts of it that are relevant to ensure you have the right public key.

But a PGP public key can contain more information than that; for example, it can contain a portrait image, it can contain signatures of people who trust your key, their e-mail addresses and so on. The order of these elements may change without changing the fingerprint, and whether or not a key contains an image does nothing to change the fingerprint, because the portrait or the order in which these elements are stored isn't relevant for authenticating the key.

So it's probable that the keyserver changes some of the non-relevant parts of the key; so you get another key block, but the same fingerprint.

Imagine someone messed with Bob's key on the keyserver to change the portrait picture contained in it. The fingerprint would stay the same because even with the wrong portrait, if Alice used the key to encrypt a message to Bob, it could still only be decrypted by Bob's private key.

However, if Malory left Bob's portrait alone but replaced the modulus and exponent of the public key with his own, this would change the fingerprint, and rightly so: It would no longer be Bob's key, and encrypting something with it would give Malory access to it via Malory's private key.

We could build the fingerprint over all the elements of a public key, e.g. including all the signatures and additional personal information about the key owner, but if it worked like that, then every time you updated some trivial information in your key, or someone added another signature to it, your key fingerprint would change, and you'd have to explain to everyone that no, your key wasn't hacked, you just put in an new portrait image where your smile was more radiant.


I let someone Remote Access my tablet (connected to Wi-Fi), and I think they may have ARP poisoned my network

ARP poisoning is an active attack. They need a presence on your network to maintain it, otherwise the ARP cache will eventually reach a correct state. ARP poisoning would be something they might do to try and attack other hosts on your network, so this should be your primary concern--making sure they are no longer in your network.

Personally, I'd isolate each part of your network, then factory reset things one by one, then reconnect the network, at the end. This would include your router.

If you, understandably, do not want to do that, you should at least check that all computers connected at the time of intrusion had all security patches applied and have no record of intrusion.


Can a wifi usb adapter double as a keylogger?

I believe it's certainly possible.

In principle, the initial connection of the usb dongle loads key logger software onto your machine along with the code to capture and send keys to remote storage periodically, then switchs modes to become a WiFi.

There are a number of usb devices that support multiple modes and switching modes. I've not seen that particular combination, but it should be possible.


The goal of an XSS attack is for an attacker to somehow inject code into a webpage that is served from your site. This code is privileged in the sense that, as it was served by your site, the same origin policy lets it have full access to your site's cookies and the contents of the web page that you served.

So, if your site responds to a request such as

http://example.com/search?q=

by returning this HTML

No search results found for ""

then that script will be executed and you'll see the alert dialog. This is an XSS vulnerability. On the other hand, if your site returns:

No search results found for "&lt;script&gt;alert(1);&lt;/script&gt;"

Then you have, at least, some protection against XSS attacks.

In a real attack, the attacker would not use alert, but try to perform an action on your site as the logged-in user or steal data from the page or the user's cookies. You should read the OWASP XSS Cheat Sheet to get a more complete explanation as well as a detailed presentation of how to perform the appropriate escaping to prevent XSS vulnerabilities.


image blocked by CSP policy even though the image is never requested

There's a clue in the blocked URL:
https://www.tailwindapp.com/app/extensions/Tailwind_swoosh.png
The image reference was most likely added to the page locally by a browser extension. Probably this one: https://chrome.google.com/webstore/detail/tailwind-publisher/gkbhgdhhefdphpikedbinecandoigdel - from its description, "Schedule any image on the web by clicking the "Schedule" button when hovering over it." sounds like something likely to inject images (and other things) into arbitrary web pages.
Of course there won't always be this sort of clue, but browser extensions are often responsible for mysterious unexpected requests like this. Troy Hunt writes about the problem here. Client-side malware is another possibility.


NMAP port scan on home router looks strange to me

23 - for TELNET connections (remote shell, insecure)
22 - for SSH connections (remote shell, secure)
53 - DNS lookups
3000 - PPP is a method for connecting to the WAN
631 - IP printing
80, 443 - are the standard admin web interface. 443 is for HTTPS, 80 for HTTP
8081 - This one is slightly harder. It would generally be used for a web service of some kind. It is also possible that another device on your network has opened this via UPnP.

So yes, all of those are valid for the internal port of a router.

Every open port does, of course, carry some risk and it is better to close any you don't actually need but that is dependent on the router actually allowing you to. The moral here is that most consumer routers are terrible for security! Not only do they leave ports open that aren't needed (purely to make things simple to configure) but they rarely get firmware updates to keep them secure.

Ideally, you would want to close ports 23, 80, 631 (if you aren't doing printing via the router). 3000 may not be needed but you would have to test that. However, it is unlikely that the router provides a method to do this.

If you want better security, go for a router that allows replacement firmware in the form of OpenWRT or for a make that understands security such as the EdgeRouter Lite from Ubiquity. They may not be quite as convenient to configure (though even that is certainly up for debate) but the get far more updates and generally get any issues dealt with quickly.


Are random URLs a safe way to protect profile photos?

It depends entirely on what you mean by "safe".

If your only concern is an attacker guessing URLs, then 16 alphanumerics gives roughly 8,000,000,000,000,000,000,000,000 possible addresses, which is plenty to stop random guessing -- in order for an attacker to have a 50% chance of finding even one picture on a site with a thousand users in a year, they'd need to make 100 trillion tries per second, enough traffic to bring down even something like Amazon or Google.

But there are other ways for URLs to leak: people putting them in emails or blog posts, web crawlers finding pages you didn't secure adequately, and so on.  If you really need to protect something, you need to put it behind the same sort of security as the rest of your website.

Personally, for making hard-to-guess URLs, I'd use GUIDs/UUIDs.  The search space is absurdly huge, you don't need to coordinate generation between multiple servers, and most languages have standard routines for handling them.


Cordova/Phonegap: RefreshToken in localstorage

Well, according to PhoneGap/Cordova security guide it seems that localstorage is not recommend to store sensitive data.  So what you can do?

Well, here are two options I think you can use.

1- Encrypt the refresh token and store it encrypted in the localstorage. You can use CryptoJS (a JS library to encrypt/decrypt the data) to encrypt your token using AES (see this example) and it also has an angularjs module

2- You can store your refresh token on the device/phone file system using the Cordova File APIs. For extra level of security you can encrypt the data and store it on the device file system. Note on android you will be limited to AES 128 bit key size but using some third party plugin you can increase it to 256.


If you're talking about cracking passwords and not stealing them by other means, then there are only two techniques: online (query API over and over to try to get the password right) and offline (run the hashes through a hash cracking program). Both of the techniques can be subdivided into brute force, dictionary attack (customized for the target or not), and a hybrid of the two (e.g. HashCat rulesets).


Exchange sensitive information through public chat

Using an asymmetric encryption.

Create a public/private key pair.
Share the public key in chat
Now someone can send data to chat encrypted with your public key.
Data can only be decrypted with your private key no body but you can read it.


Does Google check for Unicode characters to determine spam now in Gmail?

Yes, Google checks for unicode homoglyphs in email now. This is primarily done to make it easier to recognize spam, but it also works fairly well against many phishing attacks. This change was actually done in 2014. In particular, they are using an open standard from the Unicode Consortium for restricting homoglyphs. However, while this does improve security, there are a large number of potential ways to bypass it. A presentation from DEF CON 26 went over some of the possible ways to bypass such detection mechanisms and why it's so difficult to comprehensively detect such attacks from software.


The tool you need is called HashCat.
In the first instance, you need to specify or extract the stored+salted hash that is within the zip file, eg:

hashcat -m 13600 "your_zip_file.zip" ^ (for 7z zip files)
7z2hashcat (for 7z files)

(^ See this discussion on various zip formats in hashcat: https://forum.hackthebox.eu/discussion/3783/zip-password-crack)
Then, you need to configure hashcat to limit the range of characters from which it will draw its possible combinations. This is addressed in the documentation.
edit: to clarify: you don't specify the total number of possible characters in your question, so it's not possible to predict or speculate on possible hashcat configurations, however, the tool allows you to specify the charset that applies for a particular placeholder, viz. https://hashcat.net/wiki/doku.php?id=mask_attack#examples - in your case I would recommend creating more than one (max four) custom charset with the possible known characters at various regions in your password - the more constraints you can impose, the less the total number of tests that must be executed.
Depending on how many possible combinations there are, you may wish to parallelise the operation. This is beyond the scope of this answer, however, here's an idea about how to approach the problem: Hashcat performance on AWS EC2 GPU instances de Koning 2019
Let us know how you go ... good luck!


The page on GRC actually explains why this occurs.   Google has a massive infrastructure, and uses many certificates to protect HTTPS traffic, not just one.  Each of these certificate has a different fingerprint, of course.  So, even though you see two fingerprints above (because there are two different certificates here, one was used when you access the site, and a different one when GRC accessed it) both are valid Google certificates.  This behavior is as expected.


Correct, the main difference is what is sent trough the VPN. The browser based one obviously just covers the browser data, whereas the network based VPN should cover all network activity (depending on the VPN and its configuration.

Don't forget that with the browser plugin DNS requests may very likely leak, partially revealing your activity.

Other than that, the encryption itself and therefore the security of the tunnel may widely differ, depending on the type of VPN. If your browser "VPN" is for example the Opera VPN, it's more of a proxy than a VPN.

The third party, aware of your activity also changes. With the browser plugin, the providers of said plugin may have insight in your activity, whereas with the university VPN, they probably know what you're doing.

A "network based" VPN very much depends on the configuration, you can have a VPN active and connected and nothing is sent over the tunnel, because it's not configured that way. It's a question of routing and default gateways, as of what is sent over the tunnel.

There are quite a few differences and one could go into detail on every single attribute, but I think the vital point is, what do you want to protect and against whom. Starting from there, you can decide what makes more sense for you.


fgets can read in up to 28 bytes into an 8 byte array.

char input[8];

...

fgets(&input[0], 28, stdin);

Type in 28 bytes of data when prompted, and you'll overflow the input variable.  This means that the both guess and number will be overwritten with the first 8 bytes of data past the 8 bytes the array can hold.  Any more data provided will continue to overwrite stack protections, and eventually the return address of the function (and beyond).

You can learn more about buffer overflows in this question.

This can be mitigated by making sure you don't read in more bytes than your buffer is allocated.


Like mentioned above, it's only a way of marketing their products. Every computer can be hacked one way or another. The best way to stay safe is by logging in using a live cd(kali linux or anything else).


Should I change password after servicing a tablet?

Yes, change your password.  (I'm assuming that since you sent your tablet for repair that it was pretty much unusable, so the most likely case is that the repair people decided it was a lost cause, chucked it in the recycle pile, and sent you a new one. It's unlikely that any attempt was made to access your accounts. I would not proceed on that assumption however. As for how to see if anyone has tried to access your account there's really no way to be sure.)

The fact is that you can still access your account, so no-one has changed your password on you, and you still have control over your account. So the first thing to do is change your password, right away. Anyone who may be using the cached credentials in your device will no longer be able to do so. If someone had tried to take over your account they would have changed your password and the secondary email account to keep you from re-setting the password.

Before I stop using a mobile device I always wipe it, plus any additional storage on the device, however when a device breaks you may not have the ability to wipe anything. In that case all you can really do is change all your passwords before sending the device in, and hope that nothing personal can be recovered on it.


Whatever your strategy, I think the first step is to sign your patches. No matter how many MITM there are, if the users can check your signature in a way they trust that will already provide a massive amount of certainty.

HTTPS is good, but it doesn't really do as much as the signature on your patch, HTTPS will make MITM more difficult, but not impossible.

If you open up auto-updates (configurable, of course), that means you also open up an attack vector. Depending on your philosophy, you can either choose to minimise the attack vectors to highten certainty, or you might feel that getting the security updates in your patches out wide and quick justify the increase in complexity.

You can also look into ways of providing out-of-band checksums, e.g. on external domains or over SMS. It is a lot harder to MITM your domain and your modem number than it is to MITM just your domain. Users that want certainty could use these checksums to see if the program they are running is the right one or if the patch they're accepting is valid. If any of the checksums disagree with another, that's a sign something fishy is going on.

As for the protection of patches within your server, taken far enough you are actually trying to protect against "authorised" intrusions and you want this protection to be verifiable by your users. This is quite a tricky thing to do.

If your project is open-source, you might look into deterministic builds, which Tor tries to do. This way a user could inspect the code (but no one does), and compare their build with yours. Might be lots of work and/or incompatible with your current platform.

If you persue using multiple keyholders or servers you might end up chin-deep in Byzantine fault tolerance, which you and your users might find an enjoyable endeavor, or you might find it to be difficult and tedious to work with.

Whatever you choose to do here, just try to keep it simple. As per AviD's law:

  Security at the expense of usability comes at the expense of security.


In order to tell the end user that the YOU are the actual owner of the app, you MUST buy a certificate from a trusted third party (a party which is also trusted by Windows). These third parties are called Certificate Authorities (CA). Here's how you can get a certificate from a CA (according to MSDN).

  How the end user will know its from him, not from me. Or Its doesnt
  work this way ?

Now, one of the responsibilities of a CA is to verify your identification before issuing you a certificate. Therefore, no "other guy" can get a valid certificate with your identity from a CA. Your certificate is verified by the Windows through a process called Chain of Trust verification. You can find more details about the process here.

  As far as I understood, when creating own certificate, it needs to be
  added in some sort of store so Windows can recognize it ?

I think the store you are talking about here is the Microsoft's Certificate Store Technology which is basically used to store all your certificates, so that you can choose them while signing. Also, you don't have to worry about availability of your certificate at end user. Since your certificate is signed by the CA (CA trusts you) and Microsoft trusts that Certificate Authority and End user trusts Microsoft, user will have no problem identifying that the code belongs to you.


Because of the way SSDs manage writes, it is not possible to truly verify that data has been erased without modifying the low-level firmware on the drive itself. Below are the features SSDs have (wear leveling and overprovisioning) that make erasing data problematic. If you already know all that, skip down to "ATA Security Erase", which is the only solution to erasing all data.

Wear leveling

Data on SSDs is stored in "cells". A cell may only have a lifetime of 10,000 writes, so a way to allow you to write to a single file more than 10,000 times without breaking your drive is necessary. The technique used is called wear leveling, and the way wear leveling works is, when you send a command to write to sector A, the drive does not actually write to physical sector A. Instead, it picks a random sector (or a sector which has not seen much use lately), let's call it B, and writes the data there. It will remember that logical sector A maps to physical sector B, so accessing sector A retrieves the contents of B. However, if you try to write a second time to A, for example to overwrite it, the SSD finds a new free sector, C, and writes to that instead, merely updating its mapping to remember that A now points to C. The physical sector you wanted to erase is never touched until it happens to get chosen as the destination for another write down the line.

Note that this is a bit of a simplification, as modern SSDs actually use static wear leveling, which gives sectors under heavy writes a rest by exchanging their data with sectors that have not changed in a long time. What I described was dynamic wear leveling, but for the purpose of this answer, they are functionally equivalent.

Overprovisioning

Imagine your drive is so full that only a couple of sectors are free. Now what if you start heavily writing to the free space in the drive? The wear leveling would be ineffective because it only has a few cells to choose from, and those cells would rapidly break down. A way to prevent a full drive from breaking was needed, and it is called overprovisioning. Overprovisioning enhances wear leveling by making the drive report less storage capacity than it actually has. An N GB drive (drives are measured in GB, which is a multiple of 1000) may actually have N GiB (with GiB being multiples of 1024) worth of flash cells. By making some of it inaccessible, even when the drive is reporting it is 99.9% full, it may actually only be 80% full. This means that, even if you have only a few sectors free, you can still write heavily to the drive, and it will still be able to spread the wear out among many more cells. In other words, the number of physical sectors exceeds the number of logical sectors. Unfortunately for data erasure, this means that even filling up the whole drive does not overwrite everything.

In terms of implementation, the overprovisioned space is essentially equivalent to a version of the HPA (Host Protected Area) which contains nothing and who's size cannot be modified.

TRIM

TRIM is a feature which allows the operating system to request that the physical sectors pointed to by a certain range of logical sectors be physically deleted ("flashed"). It is intended to mitigate an issue called write amplification by letting the SSD know which filesystem blocks have been deallocated and marked as free. Without TRIM, an SSD will faithfully keep even this unallocated data, as it has no idea if it's actually being used by the filesystem or not. When TRIM tells it to delete a range of sectors, it destroys them and marks them as free, making wear leveling more effective. However TRIM is also capable of securely overwriting data. Deleting a file on a filesystem marks all those blocks as free, and the corresponding sectors will be communicated to a TRIM-capable SSD by the operating system, which will securely erase them. In theory, you could even TRIM an entire drive, destroying all the data on it, but there is no guarantee that the SSD will behave the way you want it, rather than, say, ignoring the overprovisioning area or deferring erasure to a garbage collector later down the line.

ATA Security Erase

The only way to securely erase an SSD is to use the ATA Security Erase feature, present on all ATA6-compliant drives (i.e. virtually all modern ones). Attempting to overwrite data on an SSD will not actually remove everything due to overprovisioning space mentioned above. Unfortunately, because of this overprovisioning space, you cannot actually read everything which is present on the drive, as this space is always hidden, so you cannot verify if you have overwritten everything.

ATA Security Erase is designed to solve this problem by doing a low-level overwrite of every single sector. On some newer SSDs, an additional feature calld ATA Enhanced Security Erase can be used to destroy a master key which the drive uses to transparently encrypt and decrypt your data. Destroying the key is instantaneous, but renders all the encrypted content inaccessible.

There is no way to know whether or not ATA Security Erase succeeded or was implemented correctly, but modern, fairly well-regarded drives such as Intel SSDs are likely to implement it correctly. If you want, you can spray your drive with a constant pattern and initiate the security erase, then search through your drive for that string. While that won't tell you if the erasure worked, it will tell you if it did not work.

How to accomplish this on Linux

Linux has all the tools to do this. Here is how I would do it, assuming the drive is /dev/sda.

# it must say "not locked", "not frozen", and "supported: enhanced erase"
hdparm -I /dev/sda | grep -A8 "^Security:"

# overwrite the drive with a repeating pattern to check for after
yes "You should not see me" > /dev/sda

# begin the erasure, without using a password
hdparm --security-set-pass NULL /dev/sda
hdparm --security-erase-enhanced NULL /dev/sda

# check if the repeating pattern is anywhere to be found
strings /dev/sda | grep "You should not see me"

Writing a repeating string, erasing the drive, and checking for that string is not particularly fast, efficient, or reliable, but it's the closest thing to what you are looking for.

In some cases, the BIOS sets the drive to "frozen", which prevents various actions like ATA Security Erase. This is a poorly-thought out way to prevent malware from locking your drive. Because it's the BIOS which sets this, you can often unfreeze a drive by plugging it in after the system is already powered up (make sure it supports hotplugging!), connecting it to a SATA adapter (note that not all USB to SATA adapters support ATA commands), or, in some cases, suspending the computer and resuming from suspension. As long as it is not frozen or locked, the above commands should work.


YES

SOCKS5 is a proxy, which means the traffic will go directly to it before the target. There is no encryption, so everything is plain text.

Taken from https://unix.stackexchange.com/

  SOCKS5 is just a transport protocol on top of TCP/UDP but below application layer. Thus it's comparable with TCP and UDP, too. There's no inherent encryption in SOCKS, but you application has to care about this (it's not a VPN technology, but a proxy at last). If you want encryption, the protocol you speak inside of the SOCKS-channel has to provide it.

SOCKS5 is there encryption between client and proxy server?