HTTPS IP devices and certificate best practices, why can't I sign a certificate for my local ip device?

Here some ideas and options for your network.  Hopefully, they can help you manage SSL / TLS with your cameras and devices. The options focus on your Axis cameras but may apply more broadly. However, without specific details on your network certain assumptions may not be accurate.  I have no experience with pfsense firewall.
Issue #1: you can automate uploading ssl certificate to Axis cameras via sftp, scp or ftp. Axis stores the ‘in-use’ certificate in /etc/certs/web/server/http/0/server.pem.  Older cameras (ie: P5512) use boa/stunnel for http/https.  Newer cameras (ie: Q6115) use apache for http/https.  The server.pem certificate file contains the private key (unencrypted) and certificate in pem text format.  You can replace this file and the Axis camera will not know the difference.  You must first have any certificate uploaded via Axis setup (self-signed works) and HTTPS configured for use and then replace the server.pem file leaving Axis https configuration alone.  Axis will overwrite or delete /etc/certs/web/server/http/0/server.pem if Axis HTTPS certificate setup is changed.
NOTE: you must reboot camera or restart apache or stunnel to load the new server.pem file you upload. If the server.pem file is missing on boot, it will be generated from active certificate set through the Axis setup HTTPS page.
So, if you have the private key file and certificate file for domain.com, you can manually create the server.pem from a command line $ cat domain.key domain.crt > server.pem or similar means and upload it.
Issue #2: Separate certs for each device might be a lot to manage. A wildcard cert would be best if you require different domains/sub-domains on each camera or device. Also, I am not sure wildcard compromise any risk, depending on what you mean here, if devices have unique or same certs.
Here are some options.  Other options exist, but I feel these best fit your case.
Option A: Depending on how your Cameras are setup, the following option may be viable but may require changing camera http ports. If all your cameras are behind a single global IP, that may be to your benefit.  As I am sure you know, Axis cameras default to port 80/443, but those are typically changed to keep unintended traffic down especially on public facing cameras.
Whatever domain you own, let us call it domain.com, you may be able to use that certificate on all your cameras and using port-forwarding with each camera having a unique port for http/https. Each camera mjpg would be accessible at https://domain.com:port/mjpg/video.mjpg.  Your HTML  tag would use domain.com:port (https port) and your router/firewall would forward it to the internal IP address:port. Since SSL certs are not port specific, a single certificate for domain.com (which you probably already own) would work on each camera.
I have 2 Axis cameras that I use for testing behind a router which use same certificate where the router port-forwards to each device.  All requests (internal and external), ie: your  tag, would use domain.com.
Option B: Albeit probably not ideal depending on bandwidth (fps and resolution) and number of concurrent  views. If you have Apache server, you can use ProxyPass setup to translate insecure http mjpg to https. It sounds like your server is on-site, so this might be an option if bandwidth is not too much for server.  Not ideal, but it does work, and you would not need certificate on cameras except on the web server itself at domain.com.
Also, assuming Apache server, the RewriteMap directive can help to map url to host (camera) which may help management as your web pages can use same img URL even if cameras change IP address, port, etc. If not Apache, other servers may implement similar.
Lastly, Axis Technical Support has been excellent when we have needed them.
Hopefully, this gives you some ideas.  I would pursue using your domain.com certificate on all cameras (devices). If it works, maybe buy for longer term to minimize management.  I also recommend testing manually before automating as there are always some surprises, but once you get a working solution, automate as needed.
If anything isn't accurate or doesn't work in your scenario, please let me know. I have quite a bit of experience with Axis Cameras, as they are complex and the state-of-SSL today has made things more difficult.
Best Wishes


Getting subscribers on website from nowhere?

This doesn't sound like a natural influx of customer. Something fishy is probably going on.

I would guess that this is a bot. So why would a bot sign up for your newsletter? It is probably looking for bulletin boards or comment fields or anything where it can post spam. Since bots can be quite dumb, it doesn't understand that it is just a newsletter it is signing up for, and that there will be nowhere to post spam after signup. I would not be surprised if this kind of bots operate on the principle "try everything, and hope that something works".

Another less likely explanation is that someone (perhaps your competitions) is trying to get your newsletter blocked as spam. If they sign up random people who do not want it, some of them will flag it as spam which could lead some spam filters to block your email adress. But for a newsletter about seeds with 100 subscribers this sounds a bit far fetched, and just a tiny bit paranoid and conspiratorial.

If you want to stop this behavior, I see two possibilities:

Add a CAPTCHA (will stop bots).
Have users verify that they do want to sign up by sending them a link to click in an email (will stop peopble from signing up others).

Both of these will make it a tiny bit more complicating to sign up for your newsletter, so you will have to weigh the pros and the cons yourself to determine if it is worth it.


Cracking office documents and other hashes using clusters?

You can build an MPI cluster, which is supported by John the Ripper. However note that even 18 core2duos will probably not be as fast as a 150 USD GPU.


How can someone access my computer ("hack me") when my firewall is off?

The topic of firewall protections can be big if we go into details. So I'll limit myself to one idea and one example.

Possible risk with a fresh Windows install: Security weaknesses (vulnerabilities) due to software defects or incorrect / insufficient configuration.

Example of what someone might do if it's without a firewall: Probe for those weaknesses without you noticing.

One of the first thing nearly all firewalls do by default is to limit incoming connections. i.e., someone trying to probe / connect to your computer would not be allowed to, without your permission. This greatly reduces exposure of any security weaknesses. Any complex software such as Windows with mulitple other software running on top, is likely to have many weaknesses unknown to general public - so it is a big risk.

If you connect through a home or an office LAN, you are relatively less exposed since the Internet gateway/router you use will most likely limit incoming connections that you don't specifically configure (effectively acting like a limited network firewall). However, inexpensive routers themselves have security problems that have in the past, allowed (and probably still allow) attackers to use the routers to discover and attack computers on the LAN - so having a host firewall (such as the Windows firewall) is an important defense to avoid this.


If you want a simple yet secure signature scheme, take a look at Full-Domain-Hash (FDH).
Properly randomized padding (as in PSS) can strengthen the scheme against chosen-plaintext attacks. AFAIK the main effect is that it improves the tightness of the security proof a bit, which I consider a relatively small advantage.

But since the attacker can choose arbitrary values as padding, improperly randomized padding can also cause weaknesses. Yours allows the attacker control over most of the message.

Assuming you're using big-endian encoding, the message hash will land in the least significant bits in your scheme. The attacker has full control over all the other bits. This means the padding is clearly weaker than even PKCS#1v1.5 padding.

I expect practical forgeries, at least for small values of e.


So I just got a voicemail from a random person, where it says 3 random numbers (for example 354) and then "goodbye"

This is a cut message.
Your voicemail picked the phone: "Kevin Phelan is not able to talk with you, you may leave a voicemail if you wish..."
At the same time, the calling bot started telling its offer "Hello dear customer, we will sell you the most delicious pickles you have tasted, please call us back at the 123456"(The voicemail intro ends and starts recording) "279. Goodbye"
Of course, we have no idea if they wanted to sell you food, furniture, encourage you to vote, or if it was a call providing a 2FA code.
The fact that there is a goodbye hints that there was some more text at the beginning, that would probably identify what their numbers were for.
Note that even if it was for 2FA, there's no harm by not having picked it. On your next legit login you would get called again, you don't need a 2FA code provided in a missed phone call.


No.  Digital signatures are not sufficient for non-repudiation -- not by a long shot.
Non-repudiation is a legal concept.  It means that, if there is a dispute, in a lawsuit it will be possible to hold one party to their commitments.
For example, mathematical schemes that claim to provide non-repudiation have to withstand the "jury attack".  Some expert witness is going to have to be able to explain, in non-technical terms that an ordinary juror (and judge) can understand, why the mathematics proves anything at all.  Meanwhile, an expert witness for the other side is going to be arguing the opposite.  If the scheme uses fancy mathematics, it is likely to be incomprehensible to the jurors and the judge, and hence not likely to be of much use in a lawsuit.  This is a kind of attack that most mathematical schemes in the literature are unlikely to be able to stand up to.
I'm afraid much of the cryptographic research community has screwed this up.  Researchers have written many technical papers that claim to address "the non-repudiation problem", trying to solve it with mathematics -- but what they've failed to accept is that there is a tremendous gap between the crypto-mathematics and the pragmatics and legal issues.  And unfortunately, the hardest part of the problem to solve is not the mathematics, but rather the pragmatics and legal issues.  Unfortunately, this seems to be a long-standing blind spot within the cryptographic research community.
Here are some of the challenges to achieving true non-repudiation that a court or lawyer would be satisfied with:

Malware.  What if Grandpa's computer is infected with malware, which steals his private key?  Are we going to hold him responsible for anything signed by that malware -- even if it means he loses his house?  That'd be ridiculous.  In particular, an easy way to repudiate is simply to claim "my private key must have been leaked/stolen".
Similar remarks can be made about social engineering.  When social engineering attacks have a good chance of being successful at stealing the private key, and when the scheme is designed in such a way that ordinary people cannot use it securely, and when the designers know (or should have known) this, I think it is questionable whether jurors will be willing to hold Grandpa responsible, simply because he got screwed by a poorly-designed security system.

Humans vs. computers.  Legally, non-repudiation is about the actions of a human.  A court is going to be looking for evidence that a human (e.g., Grandpa) assented to the terms of the contract/transaction.  The cryptographic schemes cannot achieve that.  They can only show that some computer performed some action.  Cryptographers like to assume that the computer acts as an agent of the human and the computer's actions can stand in for the human's actions, but this is not a reasonable assumption.  For example, malware on the person's computer can apply the private key without the human's consent.
Basically, most of the cryptographic research into non-repudiation schemes has the wrong threat model.  It is based on assumptions that we've since discovered are faulty.

If you'd like to learn more, there has been a great deal published on these gaps between what's called "non-repudiation" in the cryptographic literature vs what lawyers would accept as adequate.  Here are some example publications where you can read more:

Carl Ellison, Non-repudiation.

Ross Anderson, Liability and Computer Security: Nine Principles.

Brian Gladman, Carl Ellison, and Nicholas Bohm, Digital Signatures, Certificates and Electronic Commerce.

Adrian McCullagh and William Caelli, Non-Repudiation in the Digital Environment.

Michael Roe, Cryptography and Evidence.

Peter Gutmann, Digital Signature Legislation.

Greg Broiles provides a legal perspective on non-repudiation.


I'm not going to answer all of your question especially diving into the x509 format is probably out of the scope of an answer here but let's look at the ciphersuite examples you gave and interpret them:

TLS-RSA-WITH-AES-128-CBC-SHA256

This uses RSA for key exchange. In other words, the client picks a key, encrypts it with the servers public key and sends it over.
The actual payload is encrypted using AES-128 in CBC mode and authenticated using HMAC-SHA256.

TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA

This uses ephemeral keys from an elliptic curve DH key agreement. The host is authenticated using an RSA signature. The payload is encrypted using 3DES (EDE = encrypt-decrypt-encrypt) in CBC mode and HMAC-SHA1 for authentication.

Here is the list of ciphersuites with their specifications.

All the suites you mention use RSA or PSK for the authentication.
So the only key you will find in a certificate is the RSA key.
A PSK cannot have a certificate since it is a symmetric key and getting it certified would mean giving away and putting the secret key in the public
certificate. So the only key you have to look for in certificates is an RSA key.

The DH agreements create new keys and are also not found in the certificates.

Edit: Please don't try to parse x509 yourself. It's notoriously hard and has lead to many exploitable errors in the past.


What kind of safety does software isolation (e.g. in operating systems) offer (e.g. between OS and browser)?

TL;DR
It's the most basic form of an anti-malware, long before a traditional antimalware works.

Consider that an OS is a software ecosystem where multiple applications developed by multiple parties interact. Exactly like a big bazar where multiple merchants offer services and goods to the same customer. They must share the common space. And some may be evil under any extent.
Sharing of resources
Isolation between kernel mode and userland mode allows OS to prevent an application from stealing too many resources, making it safely crash when it comes to requesting too much memory or disk space. In this scope, OS also prevents an application to take control of disk by overwriting data related to another application.
Memory isolation
Applications may contain sensitive data. Your OS stores your user password, or at least its encrypted form, in memory. If OS did not isolate its own memory from the app memory, any app can tinker with your user password.
Not to mention with your Bitcoin wallet...
Fault tolerance
Do you really want an application crashing to reset your entire device?
Think for a second: you are on a Skype work meeting and your favourite messenger application crashes because of a bug. OS makes the IM crash, and notifies the event, but your computer/tablet will not reboot so you won't have to explain your boss why your video was interrupted.
This third case covers unintentional faults.


Security implications of allowing websites to open TCP sockets

Allowing arbitrary TCP sockets originating from the web browser means that an attacker can use the browser as a trampoline to connect to arbitrary services on the users local network. This can for example be local mail servers which often are setup to trust any internal system to send mail and thus can be misused to send phishing mails which look like they came from a local system or simply to send spam. But also other services could be affected.

WebSockets instead are an application layer protocol on top of TCP. They start with a HTTP based challenge-response and continue with a protocol using frames which are additionally xor'ed with some previously established random key. This is specifically done so that this protocol can not be misinterpreted by unsuspecting TCP servers.

  how are they not applicable to websockets?

While it is true that WebSockets are considered much less dangerous than plain TCP they are not innocent. If there is an internal application which can be accessed using WebSockets explicite measures must be taken at the server side to restrict access to this application. WebSockets are not covered by the same-origin policy in the browser, i.e. it is possible to cross-origin connect to a WebSocket server and any restrictions to this need to be employed at the server side. See also Cross-Site WebSocket Hijacking (CSWSH).


This is a great question and one that these organizations have probably put varying amount of thought into. I can think of a few different scenarios regarding systems being out in the open like that. I'll outline them and my thoughts.

It's the most expedient thing to do - Placing these computers where they are is efficient for their business processes. They didn't consider security in any way, shape or form.
These systems are basically considered terminals These systems may be somewhat locked down. They may replace explorer.exe with some home-grown app or just run a few programs on the system with a limited desktop profile. This is a little better but still not where it needs to be. There are plenty of ways to compromise a system when you are physically at it.
They have good network segmentation - These systems have little or no ability to access the rest of the network. They are logically or physically separate from other systems, and have little or no ability to access the internet.
They have a complete workstation Security Program - They have network segmentation, but additionally they've really considered this as an attack vector. These workstations are hardened, locked-down, have full disk encryption, resident agents to detect malware, and they are limited in their ability to access the rest of the network or the internet. This is more work but of course improves the security posture of your network significantly and greatly reduces the risk of exposing these systems physically.


SSL/TLS: How to fix "Chain issues: Contains anchor"

According to nginx documentation the ssl_trusted_certificate parameter contains trusted CA certificates used to verify client certificates and OCSP responses if ssl_stapling is enabled and the list of these certificates will not be sent to clients.

Therefore I think that what ssllabs calls "Additional Certificates (if supplied)" are the certificates in the ssl_certificate file which are not the server certificate.

For me:

public.crt should contain these 2 certificates:

1) your server certificate
2) StartCom Class 1 Primary Intermediate Server CA

my-chain.pem should contain these 2 certificates:

1) StartCom Class 1 Primary Intermediate Server CA // required to validate the server certificate OCSP response
2) StartCom Certification Authority  // required to validate the intermediate CA certificate OCSP response


A pair of 'self-signing' hashing functions?


Can timing attacks over a webservice be eliminated by standardizing the time it takes to return a request?

As long as t + s is sufficient to cover any delays in responses introduced by a DDoS style attack, where s is the number of seconds.

That is, hitting a service listener that calls the above in order to encourage stuffWhoseTimingCantBeLeaked() to take longer than s could reveal to the attacker how long, on average, stuffWhoseTimingCantBeLeaked() takes to execute, once the t + s barrier is broken.

To mitigate this, you could mask this extra time by detecting when your function takes longer:

let t = timeRightNow()
let s = 1
let waitTime = t + s
let message = stuffWhoseTimingCantBeLeaked()
let executeTime = timeRightNow() - t

if timeRightNow() > waitTime
  waitUntilTime(timeRightNow() + executeTime * csprng(2,1)) # Random wait of between 1 and 2 times the original execution time (integer)
else
  waitUntilTime(waitTime)
send message

Note though, with enough requests it might be possible to get an average that will even out, leaking the time taken to execute stuffWhoseTimingCantBeLeaked().

With higher values of s, the risk can be lowered further, at the expense of performance. You could also introduce detection of whether your web service is requested repeatedly from a certain user or IP address and then rate limit the connection.


Is it bad practice to use GET method as login username/password for administrators?

This would store the login link with password and username in the browsers history. It could also be accidentally be captured by things like firewall logs, that wouldn't capture post variables.


Started seeing jQuery function calls in URL requests, what is this?

To give a broad, general answer, yes, you should be concerned with all requests sent by a user. Be suspicious of all user supplied information and validate everything appropriately.

This looks like a poor attempt at finding an XSS vulnerability. You should be worried if you have input fields that are poorly validated and filtered.

The tool that's being used to generate this traffic itself probably isn't worth worrying about.


For certain URI, is it possible to log the rule violation instead of returning access deny?

This is certainly possible, as you could have different settings per location.

According to Installing OWASP CRS:

  Once ModSecurity is compiled in you will have to specify both
  ModSecurityEnabled and ModSecurityConfig within any location block
  where you want ModSecurity enabled. An example would look similar to
  below.

location / {
    ModSecurityEnabled on;
    ModSecurityConfig modsec_includes.conf;
}

However, Nginx's blog article Compiling and Installing ModSecurity for NGINX Open Source has a bit different form for these directives, and the ability to use them directly within the server {} block:

server {
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
}

You must choose those that apply to your installation, but you'll get the idea. This example is based on the latter syntax, but if you can't apply the rules directly like this, you could simply use different ModSecurityConfig files for different locations.

The detection only mode is configured with SecRuleEngine DetectionOnly.

server {
    listen 443;
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {
       modsecurity_rules '
           SecRuleEngine On
       ';
    }

    location /business-critical {
       modsecurity_rules '
           SecRuleEngine DetectionOnly
       ';
    }
}

This is best to be a temporary solution for two reasons:

Your business critical URIs may also have vulnerabilities.
There will be a lot of noise in your logs from the constant automated attacks.

I'd suggest testing through every feature and acceptable use case. Then, find false positive detections by limiting the search to your own IP address. Once you know the rules that will cause problems to your application, you could disable them with SecRuleRemoveById and enable rest of the protection, e.g.

    location /business-critical {
       modsecurity_rules '
           SecRuleEngine On
           SecRuleRemoveById 941100 941120 941160 941180 949110 980130
       ';
    }


A CSR allows a user to get a certificate authority (CA) to give them a signed certificate, without the CA actually knowing the user's private key. An X.509 cert has a few major pieces: the subject (who the cert is for), the cert's validity period, the cert's allowed uses, the subject's public key, and the issuer's signature (that is, a signature generated using the issue's private key, where the issuer is generally a CA). A CSR has most of that info, except it lacks the issuer cert (because it's generated by the user - who is usually the subject - and sent to the issuer, so it can't have the issuer's signature on it yet). The CA signs the CSR, turning it from a certificate signing request into a signed certificate.

The neat thing is, in order to do this, the issuer never has to see the subject's private key, just the public one (which is, of course, public). The user needs to have a corresponding private key for the public key they submit, or they wouldn't be able to use the returned certificate for anything, but the issuer (that is to say, the CA) doesn't have to know what that private key is.

This is a better alternative to the simple, naïve approach, which would be the issuer generating the public-private key pair themselves, then building a cert with that public key, signing it, and sending both the cert and the private key to the user. The problems with doing that:

The CA would know your private key, at least until they forgot/erased it. Ideally, nobody else should ever know your private key.
The private key would need to be transmitted very securely (so that a third party couldn't intercept it); this is hard. Better to just never transmit it at all.
The user may want to generate the key a particular way, for example using a random number generator that they trust to be particularly good, rather than relying on the CA to produce an acceptable quality of key. (You have to expect that others will trust the CA's master key - otherwise their signature on your cert is meaningless - but you shouldn't have to trust them to actually generate your key properly.)
The user may want to re-use an existing public key, for example to keep old signatures valid if an existing certificate would expire but the key is believed to still be safe. Using a CSR, you can basically get a certificate re-issued with new validity period, allowed uses (OIDs), etc. even if you don't update the key.

CSRs are what make it possible to avoid all of these problems.


Each school's programs are different, and we can only offer feedback in general terms.

Computer Science tends to be more "R&D" focused at the code and science level. Great for designing new approaches to solve complex problems using code as a tool.

Information Technology tends to be more general at the system and product administration and architecting level. Great for learning how to design a network to meet the needs of business.

Data Science and Analytics tends to be advanced stats on steroids. Great for learning and applying statistics and machine learning techniques to find patterns in noise.

You are correct to be confused because all 3 areas could be really helpful, at least tangentially, to cybersecurity. There are 2 questions you need to ask:

What are my specific learning goals and what do I hope to walk away from the course being able to do?
Does this specific program from this school meet my specific goals efficiently?

Consider that most of what you need to know about coding or networking to do "red/blue teaming" can be learned more efficiently as individual classes or on your own. On the other hand, you could do a CompSci degree and learn security on the side. That balance is entirely up to the program you choose, your own resources, and your goals.

Don't follow a path because others have done it. This field changes so quickly that whatever was normal 5 years ago is archaic now. For instance, 20 years ago, I taught at a technical college where most of my students were CompSci grads who were disgusted that their degree was so theoretical as to be useless to be able to actually code anything. Now, most CompSci programs I know have corrected this problem and are far more practical.

Whatever you choose, be prepared for this fact: if you choose to enter cybersecurity you will NEVER STOP BEING A STUDENT! If you choose CompSci, you will need to study infosec on the side. If you choose infosec, you will be studying compsci on the side. Once you graduate, you'll be studying both on the side. From this perspective, then the only real question is about your goals and how to be efficient.

The best in cybersecurity is to crush your hackers, drive them from your network, and hear the lamentations of their modems. But be prepared to amass a colossal library to do all that.


The most likely reason why this happens is that the system truncates passwords. To check this hypothesis, you could try to change your password to something longer and see what happens: does the system recognize "thisquitelongpassword" as "thisquitelong"? If so, the system definitely truncates passwords. If not, there may be serious issues with input validation, as highlighted by @Matthew.

While password truncation may be necessary to interact with legacy systems - which also truncate usernames, see this answer on Serverfault - in general it should be avoided, as it reduces the "password space", i.e. the number of unique passwords that can be generated.

Attackers can save a lot of resources (time,money) if they know that their target system uses truncated passwords, since they know they don't need to try passwords longer than the truncation length.

While your behavior doesn't seem malicious to me, some organizations are very sensitive about people finding flaws in their systems.

Therefore, you might try to tell your university about this, but don't stress too much your knowledge of possible attacks. Just saying something like "I read this can be sign of a security issue" should be fine. Also, don't state things in an absolute way like "this is completely unreasonable", as there may be reasons for that (for password truncation, not wrong input validation).

Obviously, don't perform too many tests, don't automate the tests, and don't carry out attacks.


Do certain Virtual Machine programs "Sandbox"/protect the main OS better than others? Does the category of VM matter?

In the absence of bugs in any of them, they should all give similar security guarantees, though the "OS Virtualization" (jails, containers) should give the best performance as it removes the need for multiple operating systems, is quick to start, and allows the single operating system to share all of the machine's resources more effectively. (Modern operating systems use all otherwise-unused RAM as a filesystem cache. When you run a second OS in a VM, you have to give it a specific amount of RAM. The virtualized OS will use all of that RAM, and has no way to give up some of the RAM as "unused" to the host system to let the host system use it as it wants.)

However, OS Virtualization (jails, containers) gives the untrusted code access to the host OS's kernel, which is a large surface area where privilege-escalation vulnerabilities are often discovered. Privilege-escalation vulnerabilities are more rare in Full/Hardware virtualization systems (Virtualbox, etc).


Hosted Payment Page - Security perspective implementation

Summarizing my understanding based on question and comments:

You are using PxPay 2.0 from Payment Express
You using the Redirect method (as opposed to Iframe)
You expect the customer's browser to return to you via the UrlFail/UrlSuccess you specify
You expect Payment Express to also notify you of status via UrlFail/UrlSuccess
Your concern is whether sensitive information might be sent to UrlFail or UrlSuccess, and exposed by lack of encryption

While it's not explicitly defined, all the examples in the PxPay 2.0 Integration Guide show that all calls to the UrlFail/UrlSuccess URLs include two parameters, result and userid:

The result is described as needing to be 'decrypted', but as the decryption process is to look up the meaning with another call to Payment Express, it's almost certainly just a session token with no semantic content, and not useful to anyone without your Payment Express account credentials.

The userid is the username portion of your Payment Express account credentials.  While it would be preferable to keep this "secret", and therefore HTTPS would be better, bear in mind that it traverses the customer's browser during the redirect process and therefore is vulnerable to being disclosed, and its secrecy is not a security requirement.

Therefore, I would say that encryption is preferred for your UrlFail and UrlSuccess, but not necessary - there is no information there that is otherwise unprotected by the need for proper credentials to access it.


And more specifically ECDH is the Elliptic Curve variant of Diffie-Hellman, used here for key exchange. Almost certainly in the form of ECDHE, ephemeral ECDH, but we can't confirm that from the information here.

You can't say "the" cipher on the server; practically all SSL/TLS implementations support multiple ciphersuites (abbreviated, imprecisely, ciphers). Normally the client offers a big list of suites that the client supports, and the server chooses the "best" one among them that the server also supports, where exactly what is "best" is complicated and there are (many) other questions on that. Even if I ass-u-me AD means Windows Active Directory, I don't know what suites that supports and I believe it depends on your versions of Windows and possibly of AD neither of which you stated.

Your Java6 attempt to host1 clearly offered at least one suite using ECDH that the server chose, but which failed to work in the Sun PKCS11 provider. I'm not certain about Solaris but the Windows and Linux Java6 distros from Sun did not include a builtin ECC provider and thus would not offer (or agree) any ECDH suite unless PKCS11 gives access to something that (allegedly) supported it. Java7 and 8 do come with ECC builtin, but if you have PKCS11 at provider position 1 it will still get preference.

Your openssl s_client negotiated a plain-RSA suite on host1. (The OpenSSL name AES256-SHA actually means TLS_RSA_WITH_AES_256_CBC_SHA; for historical reasons the OpenSSL names omit the RSA for plain-RSA key-exchange.) OpenSSL versions 0.9.* do not support ECC by default and would produce this result. (Technically you can get 0.9.8 to do ECC if you beat it enough, but I assume you would have mentioned that.) OpenSSL (upstream) 1.0.0 or greater supports all standard ECDH suites and prefers them, which I would expect to cause the server to select one. I know RedHat packages of OpenSSL omitted ECC until recently over patent concerns; obviously RedHat wouldn't apply on Solaris, but conceivably the (a?) Solaris packager might have done the same thing. It's also possible somebody tweaked your build to support ECC but not prefer it, and the server followed that preference. You might try adding -cipher ECDH:!aNULL and see if that succeeds in getting some ECDH suite and if so which.

Trusting wildly with Java: In any case, with openssl you don't need InstallCert. Do

echo Q | openssl s_client -connect $host:$port -showcerts \
| nawk '/--BEG/,/--END/{print>"anchor"} /--END/{close("anchor")}'

i.e. add -showcerts and select the last block of certificate data into a file, then

 keytool -keystore $YOURJRE/lib/security/cacerts -importcert -file anchor -alias $NAME

where $NAME is a brief name of letters and digits only mnemonic of your local authority (domain or whatever), and enter the password changeit and confirm.


Why do IPSec VPN Phases have a lifetime?

This is the Security Association (SA) lifetime, and the purpose of it is explained e.g. in RFC 7296, 2.8 on rekeying IKEv2:

IKE, ESP, and AH Security Associations use secret keys that should be
used only for a limited amount of time and to protect a limited amount
of data. This limits the lifetime of the entire Security Association.

If we used the same keys forever, any compromise of the keys would compromise all the data ever encrypted in this tunnel. The SA lifetime puts limits to the time window. IKEv2 also improves this compared to IKEv1:

A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request
the rekeying.


At what point is deleted data irrecoverable?

This depends a lot on what medium is used to store the data and what you consider "irrecoverable".

"Deleting" data mostly does not what most people think it does.
Simply put, after a standard deletion, the data isn't gone but only the link between "Data XY lies at 0x000000" and the actual storage location 0x000000 is being deleted. Your data is still at 0x000000.
File recovery programs will easily restore this data.

HDDs: When deleting data or formatting/deleting partitions, you are not actively erasing the data but also only making it not actively indexed.
To actually erase the data, you need to overwrite every bit.

Actually, to make it really secure, you need to do that multiple times as data on magnetic drives can be recovered even after overwriting it with zeroes.

SSDs: Wear leveling and other features prevent SSDs from actually erasing or overwriting sectors even if specifically advised to. Instead, the SSD controller writes the new data to somewhere else and creates a pointer from the old to the new, actual location. Your old data still lies on the disk.

Most SSDs offer a Secure Erase feature that is designed to tackle those exact problems.

There are research papers dedicated to erasing data on SSDs:

Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson. Reliably Erasing Data From Flash-Based Solid State Drives. USENIX Conference on File and Storage Technologies, 2011.

NIST offers an overwriting standard NIST SP-800-88 Rev. 1 that elaborates on 64 pages on the difficulties of erasing data on different mediums.


Is there a reason why I should not use the HaveIBeenPwned API to warn users about exposed passwords?

Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2; see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices.  It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against).  HIBP is just one way (and probably the simplest way) of doing this in practice.  It only requires sending off the first 5 letters of the hash of the password, so actual risk to users is practically zero.  So yes, please feel free to do it if desired.

As for why a particular organization might not do this, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:

Security is an area where many like to skimp, and implementing such a system takes additional effort.
It takes time for new best practices to become common knowledge for institutions
It takes even more time for institutions to get caught up with best practices
Every developed feature has costs: money in terms of engineering time to develop and maintain, lost users who don't understand or wish to follow the rule (h/t @Woohoojin), etc.  Organizations may not consider the added benefits to be worth the costs.

To be fair, none of my systems do this yet, so you can add me to #3 or #4.

Item #4 is worth a bit more mention.  The costs of implementing this are obvious—it takes developer time to build and maintain any feature.  The benefits are much harder to quantify.  Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1).  However, this is one feature in which the benefits are likely small.  There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs.  As a result, features like this may not be worthwhile for all businesses to implement—it's always up to each business to weigh for themselves potential costs and benefits.


Is it possible for a company such as Apple to encrypt users' data such that they cannot trace identities?

Why doesn't Apple encrypt users data such that they cannot trace identities?

Well, if they're not supposed to be able to trace the identity of their users, the simplest solution would be to not store any user identifier with the data they collect. No encryption would be necessary.

OTOH, if they do store said identifier, then it's impossible to design a system that will allow Apple to access it, and deny legal access by government institutions such as the FBI, because Apple is bound by law to assist when lawful requests are made. They might fight such a request in court, but if they lose, then they must comply or face the consequences.

So what you're really asking is why they store personally identifyable information at all, and the answer to that is probably the one @Limit gave in his comment - it's valuable to them.


Password security, "hacking" of web pages (hydra)

192.168.159.130 is the IP address of the server you want to crack and http-get is the protocol which is used to send passwords, in this case plain HTTP authentication, and /whmcs/admin/ the directory on the server. Webservers can have multiple sites and configure different users and passwords for them. So the accounts which are valid on /whmcs/admin/ might be different than those on /phpmyadmin/ or /plesk/.

That's why you need to tell hydra which directory exactly you want to crack. There is usually no way to tell how many directories with individual http password protection are configured on a server and what other functionality there is on the server which could be called an username+password authentication (like login forms).

Usually you wouldn't run a tool like hydra blind. You would try different URL paths and different protocols on a webserver until you get prompted for a password, find out what technology is used to implement that password prompt, and then run hydra on it.


Is this password inside a file secure? A security paradox

The logical flaw in the scheme is that you need to know the password in order to access the password.   This nullifies any valid use for storing the password in the first place.   So, it's not so much a paradox as a fallacy.

If your real goad is simply to store a password as securely as possible, then your architecture generally makes sense, but replace the construct of a password-in-a-file-that-requires-the-same-password with that of a password manager, when the password is stored in a password manager protected by a strong master password, and a second factor.


BOF - How to determine adress of system() using a leak memory?

You have to grab your libc binary and compute the offset in bytes from __libc_start_main+247 to the function you want to call. ASLR randomizes the base address from where the module is loaded, but it cannot randomize internal offsets between elements inside the module itself. You can find this offset in gdb by executing

print system - __libc_start_main+247

... while running the program. Hence, to find system given __libc_start_main+247, just add the value you got by running that command. Keep in mind that this offset does depend on the version of the module and the way it was built, so it may be different between systems. You can roughly guess, "if it runs Ubuntu xxxx, offset should be this", or you can make sure by means of arbitrary read primitives.


Mcafeesecurity.application-center.club is a browser redirect program presented as something that it’s not – an enhanced search engine that’s better than products offered by established names. It may certainly seem great on the surface – you’re provided with local weather, news, quick access to iHeartRadio, YouTube, SoundCloud, Amazon, Gmail, Yahoo!, Twitter, Instagram, and, of course, an ability to search the Web for information. The application is completely free, so installing it may seem appealing, but you shouldn’t trust it and, as a matter of fact, should keep it as far away from the system as possible.

http://pcfixguides.com/best-method-to-remove-mcafeesecurity-application-center-club/


Password entropy varies between different checks

Attempting to add to the other Connor's answer:

Something important to keep in mind is that entropy of course is, in essence, "the amount of randomness" in the password.  Therefore, part of why different entropy checkers will disagree is because the entropy is a measure of how the password was generated, not what the password contains.  An extreme example is usually the best way to show what I mean.  Imagine that my password was frphevgl.fgnpxrkpunatr.pbzPbabeZnapbar.

An entropy checker will probably rate that with a high amount of entropy because it contains no words and is long.  It doesn't contain numbers, but taking a simple calculation (like what Connor outlined in his answer, and what most entropy calculators do), you might guess an entropy of 216 bits of entropy - far more than a typical password needs these days (38 characters with a mix of upper and lower case gives 52^38 ≈ 2^216).

However, looking at that, someone might suspect that my password isn't really random at all and might realize that it is just the rot13 transformation of site name + my name.  Therefore the reality is that there is no entropy in my password at all, and anyone who knows how I generate my passwords will know what my password is to every site I log in as.

This is an extreme example but I hope it gets the point across.  Entropy is determined not by what the password looks like but by how it is generated.  If you use some rules to generate a password for each site then your passwords might not have any entropy at all, which means that anyone who knows your rules knows your passwords.  If you use lots of randomness then you have a high entropy password and it is secure even if someone knows how you make your passwords.

Entropy calculators make assumptions about how the passwords were generated, and therefore they can both disagree with eachother and also be wildly wrong.  Also, XKCD is always applicable when it comes to these sorts of things.


Is Java vulnerable to glibc GHOST Vulnerability in Linux?

Possibly.

The two functions that are vulnerable in glibc are gethostbyname and gethostbyname2.  You noticed that java is linked to glibc, but to even be possible to be vulnerable it has to link to these specific functions.

It's possible to scan the ELF binary and look through the linked libraries with the program readelf.

It's recently come out that procmail is vulnerable, let's check this approach works with a known vulnerable program.

readelf --dyn-syms /usr/bin/procmail |grep gethostbyname
    46: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gethostbyname@GLIBC_2.2.5 (2

And it does!

If you can the jvm executable, you won't find references to gethostbyname.

If you scan the libraries included with java, you will:

readelf --dyn-sym libdt_socket.so |grep gethostbyname
    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gethostbyname@GLIBC_2.2.5 (4)

Whether this is exploitable or not requires further analysis.  But until proven otherwise, you should update your glibc library.


chosen plaintext attacks against MD5 and SHA1

The goal of the attacker is to guess the password. By observing the authentication message, the attacker already learns enough to "try" passwords at home (i.e. an "offline dictionary attack"), but that's not what RFC 2617 is talking about at that point. Rather, it concentrates on the idea of an attacker who impersonates the server, and thus feeds "server" nonces of its choosing to the client. The client responds to such a nonce by hashing the server nonce, the client nonce and the password together (I voluntarily skip the details here). The attacker may then try to exploit some internal weakness of the hash function to recompute the password from what the client sent. What the RFC 2617 tries to say is that omitting the client nonce can only makes things easier for the attacker (at least provably not harder, and heuristically easier) -- as a corollary, using a client nonce may help in protecting the client in case the hash function is flaky; a client nonce will certainly do no additional harm.

Now no exploitable weakness of MD5 is currently known, when used in Digest Access authentication as described by RFC 2617. Even though MD5 has shown considerable flakiness with regards to resistance to collision, which is another, distinct security property that a good hash function should have (and that MD5 has not). So the protection offered here by the client nonce is only hypothetical. But, as I said, it does not harm either.


Can infection effect a phone through it's wireless hotspot, also the usb tethering

It perhaps makes more sense if I paraphrase your question:

Can a router be infected by devices connected to it?

Yes, although in such a scenario the router and infected devices will typically have very different configurations and operating systems - implying that an exploit targeting the client device is unlikely to affect the router device. And it would be very unusual (but not completely impossible) for the router to be exploitable via the traffic it routes - more likely by services exposed on the router device for control, configuration or other purposes (such as storage).

If the router is a phone then it will provide additional functionality (such as storage). But it is unlikely to provide the remote configuration functionality one would expect on a dedicated router (having its own user interface and limited number of interfaces).

Using USB tethering rather than Wifi for connectivity changes Some things - by exposing different services on the phone to a (possibly) different set of clients - e.g. it might be impossible to invoke the telephony operations over wifi, but accessible via USB. Hence (except for the case of running an open hotspot) its impossible to say if USB offers any security benefit over wifi or vice versa.

  at more risk if usb debugging on the phone was turned on

Yes, you would be at more risk - there's a bigger attack surface.

There will always be a lot more infected devices on the internet side of the "router" than on the local network interface.


Could a fake tip that my server is compromised be a social engineering attack?

The message itself isn't phishing, but it could be the first stage of a social engineering attack.

The message (that you quoted) isn't asking you to do anything specific, so it is benign. But, if you reply asking for further details, they might ask you to do something specific (run a program, log into their service, etc.), which would be an attack.

Otherwise, the person could be confused. I see no harm in replying and seeing what the next step is.


Why does MySQLi using question marks (?) instead of the sprintf formatting?

There is no particular standard for what parameterised queries look like, so it could just as well be any syntax. I'm not sure what DB layer you were previously using that preferred %s (but if it's the Python MySQLdb then the reason for that is that it's using its own non-native parameterisation function which actually uses the string format operator to drop the parameters into the query).

PHP's mysqli_prepare is implemented using the libmysql-native parameterisation C function mysql_stmt_prepare and that function decided to use question marks.

  if you needed to have a question mark in your SQL statement, is there a way to escape it

You don't need to escape it: apart from representing a parameter, the only place you can use a question mark in SQL is in a string literal. ? doesn't have special powers in a string literal, so:

SELECT '?' FROM x WHERE x.id=?

selects a literal question mark where the id matches the parameter.


Does providing non existant users with fake salts prevent user enumeration?

The main problem with the proposed system is that an attacker probably wouldn't bother with the obtaining salt step. They don't need to - the salted password is a password equivalent, so it's easier to jump in at step 3, and send pregenerated hashes to your server.

In terms of username enumeration, yes, it would be possible to determine whether a user exists given the response of salt or not. Depending on your system, it might also be possible to determine whether a user exists by requesting the same username twice. If you get the same salt (which you would need to use, in order to keep the server side storage of the password safe) for two calls, you could be sure that the user was real. You could mitigate that by storing the salts you've sent (which results in your user DB being full of junk after a couple of attack attempts) or by algorithmically generating them from the username (which would need to be applied to all users to prevent enumeration by looking for the ones that aren't generated in this way).

The proposed system doesn't really offer any security improvements over a standard username/password login, served over HTTPS, but does increase the attack area, and the information that attackers have about your system. Specifically, they know that the real passwords are hashes, with a known salt - they are a specific length, contain specific characters (probably hex digits), and are valid output for strings containing the salt.

I'd suggest sticking with the tried and tested method of username/password over HTTPS!


Is it possible to retrieve flash-based encrypted disks content (SSD, cellphones, USB sticks, ...) after password wipe/replacement?

It is indeed possible that the block containing the key cannot be properly erased. That's why LUKS uses AFsplit to store the key on disk.

The idea is essentially to expand a key that would normally be stored on a single disk block, into a format that requires many more, ensuring that the loss of a single of those blocks makes the key lost. So when erasing the key, LUKS only needs to be able to overwrite one of those blocks.

The number of blocks is configurable so as long as it is large enough, being unable to erase all of them is unlikely.

You can read more about AFsplit in the LUKS on disk format specification, and see a sample python implementation (linked from a crypto.stackexchange question).


Question about Teamviewer and visible IP address

I believe Teamviewer connections are shoveled through the Teamviewer servers.  Otherwise, I wouldn't know how most client edge devices would know to route to a client using PAT/NAT.

But yeah, like the other answer stated, it would be straightforward to check the open connections yourself to inspect the IP handle.

As for your other questions.

  browser footprints

I'm not sure what you mean by this one.  Are you talking about referring website and general tracking information? I would suppose your best bet would be to browse in Incognito/Private mode or any of those specialty anti-tracking browsers.

  user agent

I wouldn't see how, but I suppose it is possible the teamviewer client could leak/expose this information, though I'm not sure what it'll get you outside of the client version.  All in all, I wouldn't count on that information to be confidential.

  mac address

MAC Addresses change as you hit each switch, Those MAC tables are how the switches forward the packets.  A cursory look, this may help you understand.


Apple encrypts data using a CommonCrypto library and I would guess what you are seeing is SQLCipher.   Details to be found in the manual.

http://developer.apple.com/library/ios/#documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157

Also I recommend reading these:
http://mobileorchard.com/tutorial-iphone-sqlite-encryption-with-sqlcipher/
http://sokol8.blogspot.no/2011/05/iphone-sqlite-data-encryption-sqlcipher.html
https://stackoverflow.com/questions/929744/encrypting-sqlite-database-file-in-iphone-os


Stack smashing keep getting segmentation fault

Your memcpy utilization needs a review - please follow:

Your original post:
memcpy(buffer+(sizeof(buffer)-1)/2,shellcode,strlen(shellcode));

For starters, you use buffer without referring to it as a pointer - &buffer
actually, there are some compiler that can handle it, so it's not necessarily what stops you from exploiting the stack.

Now, you try to measure the buffer, decreasing by one and then cut it in half - it gives you 258 offset.
Your NOP sled now looks something like this:

  NOP, NOP, NOP X 517 --- 258 unspecified bytes -- shellcode

that doesn't make so much sense - why to leave those unspecified bytes inside your NOP sled?

Last, you make an iteration over i that cover half of your NOP sled with your guess of the return address.

Can you see your errors now?


How is HTTPS Everywhere leaking my Twitter session from an incognito window?

I'm the maintainer of HTTPS Everywhere and just merged a pull request fixing this issue. It should be in the next release (out in 1-2 weeks). For future reference, submitting these to Github means they'll get fixed sooner :). (https://github.com/efforg/https-everywhere)


How do I identify, characterize and detect if trusted CAs compromised?

... like Blockchain ...

CT is already basically the same idea, i.e. a public list of all the certificates issued by a CA.

Also, the actual problem is not if a CA is compromised. The problem is if a CA issues certificates for sites which it is not supposed to do, no matter if this is because of a compromise, change in ownership and policy or bugs. Certificate transparancy provides a public record of the certificates a CA has issued. Certification Authority Authorization provides a way for the domain owner to specify which CA is allowed to issue certificates for this domain - which then could be checked against CT records. Certificate pinning and public key pinning provides a way to narrow down at the client which exact certificate, public key or CA to expect for the certificate.

  ... which partly address some issues related to CA compromised.

I'm not sure if we actually need yet another technology or if we should use existing ones more extensively. It is impossible to tell if a CA issued fraudulent certificates unless it is clear what it is supposed to do and what not in the first place. As long as domain owners don't restrict which CA can issue certificates, any public CA can actually do. Sure, one could use human crafted or automatically crafted heuristics (i.e. machine learning) to predict what the domain owners might want based on previous behavior, but this will always lead to false positives which need to be somehow addressed.


How to find known vulnerability in third party JavaScript?

This may seem like a lame answer to you but my rule of thumb is pretty simple and cheaper than trying to validate third party JS libraries

Only use well-known, actively maintained, patched libraries like Jquery.  Look at the list of libraries available on Google and that's a great hint you are dealing with reliable code
If you are rolling your own, or on the bleeding edge - there is JS Lint. In my experience, almost all security vulnerabilities are due to bugs - see http://www.jslint.com/


protection from Backdoor hacks from disgruntled developer/ employee

For one, contracts. When you have someone develop something, make sure they can't legally add backdoor, so you can sue if they try something.
Log everything. Backdoors are hard to find in code but you can see where it is after he uses it.
Have another developer harden the critical parts of your system, that being checkout, order managment and payment processor in your case.

None of these will prevent backdoor access completely, unfortunately it is not possible to prevent completely. You should only collaborate with developers you trust.


Does this attack on RSA keys reveals a major flaw, or this is no big deal with good entropy?

The original 2012 paper the blog references attributes it mostly to using an improperly seeded PRNG, though at least some of the keys had deeper unknown issues:

  We also encountered seven components that we find harder to explain,
  the most remarkable one being a K9, a complete graph on nine vertices.

(vertices being primes, so they found keys using every possible pair of primes from these 9)

If you're using well known software to generate your keys, I wouldn't worry about anything more than proper seeding, which is known to be an issue especially in embedded devices shortly after rebooting.

For the Debian OpenSSL issue you mention though, it's not just after reboot that you have to worry, those keys only have entropy from the PID (15 bits by default) no matter when they are generated.


Good way to obtain an EV SSL certificate for personal use?

EV SSL Certificates aren't that expensive at all the CA's. DigiCert's are less than $300.00 per year at the time of this writing.

As far as getting one for personal use that part might be a little tricky because they want to verify your business via one of 3 business directory verification services.
1.) data.com
2.) Dun and Bradstreet
3.) Google My Business

That said you could easily incorporate a business (your name consulting LLC.)(price varies by state), then register it in one of the business verification services (that part is free), then finally purchase an EV SSL Certificate for your business.

Each CA may have a slightly different process and pricing. DigiCert is probably not the least expensive but this is one way to get one. All of this can definitely be done for well under $1000.00 but I'm not sure what the least expensive combination would be. That said it would be trivial to do price comparisons of the CA's and also the price comparison of registering a company in each state.

Just to avoid potential legal complexities I'd avoid registering a company in another country although I suspect it would be even cheaper.

Note: There may be other ways to do this but from my experience the business verification part was required.


How does DCOM authentication compare to RPC based authentication/auth?

Comparing DCOM to RPC is much like comparing HTTP to TCP.

In fact, DCOM actually uses RPC as the transport mechanism, when it is necessary to send the DCOM requests over the network.
RPC, as a transport protocol, does not have any built-in authentication mechanisms; DCOM has authentication as part of the protocol.

So, for Windows 2000, when the full suite of DCOM was not already available, the CA used the existing transport protocol, RPC, but had to develop a custom application protocol on top of it, to implement things like authentication and authorization.
For Windows 2003, with the pre-developed, pre-built, pre-tested, and pre-deployed DCOM available, they could just use the authentication and authorization mechanism already there.

This is why you can have the screenshot of the configuration of DCOM permissions (its built in to the OS), but not RPC (this does not exist as part of the protocol).
Moreover, since DCOM can use Kerberos as it's authentication mechanism, you can have things like limited impersonation which allows impersonation for authenticating requesters and compares the client token against an access control list (ACL), instead of the (CA) application having to custom roll its own.

  Why would software implementation choose DCOM over RPC?

Because it's available.


Can I detect malware download using Wireshark?

The response is Yes, basically what you are referring is a NIDS (network intrusions detection system), bear in mind that Wireshark is not an NDIS, so in this case you will need to do the detection/analysis by your self.

Not all the cases for detect malware are covered by a NIDS and depends on the features of the system in place, but from the perspective of the network you can detect a very high percentage of malware. Obviously, depends a lot of the type of malware you want to detect, for example if a user downloads from a site a executable file with malware over a TLS connection a NDIS is not effectively, that's why is good to have an AV.

A good source of samples is lists.emergingthreats.net if you want to play with wireshark and pcap files with malware.


Does dnssec protect against malicious registrars?

No.  DNSSEC does not protect the integrity of a DNS name if the registrar for that name is malicious (or compromised).  The registrar for grumpyavians.com is the ultimate source of authority for who owns grumpyavians.com (and, e.g., what is the public key for grumpyavians.com).  Consequently, if the registrar is malicious or compromised, then the registrar can transfer control or otherwise subvert security.

That said, I believe the situation is not quite as bad as you feared (it is not the case that any registrar anywhere can compromise every DNS name in existence).  For instance, as far as I know, some random registrar cannot take control of every domain name under .com.

Here's my understanding of how it works.  Today, Verisign administers .com.  That means that Verisign totally controls .com, and has the DNSSEC signing keys that lets it create arbitrary records for foo.com names.  There's a long list of domain registrars, who can all register domain names under .com.  The way that works is that the registrar interacts with Verisign to request that some name (say, grumpyavians.com) be assigned to it; Verisign confirms that no one already owns grumpyavians.com, then assigns it to the registrar and keeps a record of this assignment.  Transferring domains between registrars happens similarly.

Let's say you own some valuable domain name under .com (say, hungryfelines.com).  Who are your DNSSEC records vulnerable to?  They are vulnerable to Verisign, and to your registrar.  I don't believe you are vulnerable to any other registrar, assuming that the domain transfer process is adequately secured.  Caveat: the domain transfer process is beyond the scope of DNSSEC, but it is a significant potential point of vulnerability in practice.


Is it possible to get the salt if I have the hash and original password?

Getting salt from hash(salt+password) would be just as difficult as getting password from hash(salt+password).


Would I create a WiFi honeypot by setting up a fake network with a generic name like "linksys"?

Devices connect to a Wifi network through SSID. It's because that each BSSID can have multiple SSIDs(for example, one for home users, another one for guests, and so on...) and had they been connecting through BSSID, they wouldn't know which SSID to choose.

Also, in large Wifi networks, where more than one BSSIDs are required to cover a large area, a single SSID is chosen(with the same credentials), i.e, multiple BSSIDs broadcast a single SSID, so that you can roam through the large area without fearing disconnection. Your device will simply hop onto another BSSID(with the same SSID, of course), without any intervention required from user's side.


Taking a look at the Defrag Documentation of Microsoft Technet:

  Locates and consolidates fragmented files on local volumes to improve system performance.

Now, imagine that you have an operating system with 3 users, only one of them being Administrator. How could and algorithm running unprivileged manage to access files that can't be read? Would not happen. Access to those files would be denied, and the defrag process will be suboptimal, since i cant calculate how spread is a file that is not owned by my unprivileged user inside a volume. And why an unprivileged user should have raw disk access to disk? There is no reason why, and it will allow users to circunvent all protection to disk devices that the OS create and ignore the access rights implemented by the filesystem.

Situation two: Imagine that the analyze tool has some "automatic administrator" configured(like runas /user:.\Administrator /savecred defrag C: /U /V). If this software has the ability to read information about files, and it had Administrator credentials saved, it could be a feasable attack vector to extract information from other users, using your unprivileged user that is running this software. It's just a matter of time to have some bug explored on functions used to open files called by your defrag binary.

That's why you cant give disk manipulation or raw disk access to non-admin users.

Related Stuff:

Is it possible to defrag the hard disk without admin rights? - answer
Technet - Allow non-admin users to run Disk Defragmenter
Symantec - Top 5 Reasons Why Users Need Administrator Rights


How character repetition affects passwords entropy?

Password entropy is based on the number of possible combinations.
For a pattern to reduce entropy, the pattern needs to be known to the attacker.

If the pattern isn't fixed and known, the reduction in complexity will be specific to the attacker's algorithm. It will be different for different attackers. E.g., with a dictionary attack, effective complexity for dictionary words is dictionary size, for words out of the dictionary full brute force complexity.

I don't know whether there is or can be a mathematically optimal algorithm for letter repetitions. The simplest solution I can think of is to treat symbol repetitions, up to a N repetitions, as extra graphemes. In that case, the password's strength will be the number of graphemes it contains.

Against such an algorithm, the added strength of each consecutive symbol from the 2nd to Nth symbols is 0, and equivalent to another grapheme up to 2N. But such an algorithm itself will be slower against random passwords due to a larger effective character set. For instance, checking for 2-long repetitions for every symbol will drop its speed by a factor of 2^(length-1). But against a password that is all double symbols, its speed will improve to only a square root of above complexity.

If it's imperative that brute force efficiency is not compromised, a free tweak is always starting to pick the last grapheme as being equal to the previous one. In that case the added strength from the first (for variable length) or all repeat symbols at the end (for fixed length) is 0.
Doing so in the middle isn't a free tweak anymore. Neither is trying for extra repeats in a variable length password, although it's so cheap as to be nearly free.

In short, against an algorithm optimized to pick passwords with repeated characters, a password's strength can be estimated by dropping all consecutive digits past the first to get effective length L'. Theoretical strength would be approximately (charset*N)^L', where N is the maximum number of repetitions the attacker is testing for.

Against an algorithm optimized for brute-force efficiency, only the consecutive digits at the end should be dropped. Theoretical strength with a naive algorithm would be charset^(L'-1)*(charset+N). Any practical algorithm will be testing for a lot of suffixes already, though (passwords often end in "1" or "1!" to bypass complexity rules).

It's all a matter of what algorithm the attacker uses. Dictionaries, including leaked password lists, will generally be tried first.


RDRAND in Intel Celeron CPUs under Linux

The reason people are concerned about the RDRAND instruction is that it is a proprietary hardware random generator and has never been formally analyzed.  Without that analysis, there's no way to tell if it's a genuine hardware random number generator or, for example, a simple counter being passed through a cryptographic hash.  In the latter case, the output will look random, but someone who knows the starting point of the counter knows exactly what numbers will be generated.

Anyone can look at the Linux source code for /dev/random and confirm that the kernel is mixing RDRAND output into its entropy pool in a way that doesn't reduce the amount of randomness available, even if RDRAND is hopelessly biased.

Whether you can trust RAND_bytes or not is a judgement call you'll have to make for yourself, but what I can say is that running it on a Celeron with RDRAND is no worse than running it anywhere else.


Are there XSS vulnerabilities while image preview before uploading it?

No, there's not. If someone wants to attack one's own machine with JS, devtool's console tab is much easier than crafting a bad svg. XSS is only a problem when malicious code is shared with other users. If the user was unaware the file was malicious, it could present a problem, but it's not yours to deal with.

Furthermore, the origin/protocol context in which a preview image would be displayed (data: or blob:) should protect your site from being reached by a bad image's code anyway (though some zero-days or whatever could be possible).


Are there methods for determining the exploitability of bugs, after a crash is found in fuzzing?

If this is public application and you can install it on your computer so you can debug it with any debug software you want, for example with immunity debugger and than you can analyse the crush and see what happen in the cpu registers and memory when the crush happen and find a way to inject your code (shellcode) in the right place so the application will run it..


Ethical hacking requirements on a banking institution

As far as I understood, the question is whether you would use your own, "real" account, a freshly created account or a test account provided by the bank.

From my experience, any company wants to limit the potential impact when doing penetration tests. Therefore, they probably won't be happy if you start attacking their production systems. Just imagine what would happen if some of the servers crash or hundreds of users are locked out of their accounts because you are bruteforcing usernames or alike.

If you want to do a penetration test, get the support of the institution and - if available - access to some testing environment. Yes, this won't be identical to the "real" system - but there is probably less danger for both of you. And you don't want do get in troubles, right? ;-)


SOX Compliance - Is Running EOL Equipment Considered a Violation?

I will avoid going into detail about the nature of SOX as that info is widely available. However, I will say the following: SOX is not a control framework.

The answer is no, having EOL elements as part of Production is not a
problem (under the umbrella of SOX). Best practice/security/etc-wise
is another topic. Further, "every piece of technology" would not fall under SOX; only financially significant systems (and ancillary ones) are "in scope" (management and the audit team determines this).

Did your companies audit team bring this up? Asking as auditors don't think or communicate clearly most of the time and they may be trying to allude to something tangental.

My background: Part of my CV include 6 years as an IT Auditor for BIG 4 public accounting firms.


Can I trust a ubuntu repo mirror in a less 'free' country?

Take a look at man apt-secure, apt has done signature checks on release files for well over a decade. The release file contains a hash of all files in the package, and the release file gets signed by a trusted key that is included in the original installation media.

It looks like md5 is still widely used here, which is concerning but not necessarily a deal-breaker (collision attacks on md5 have been around for a long time, but preimage attacks aren't yet possible). It's not difficult to imagine a non-malicious file being included in a package that has the same md5 hash as a malicious file, in which case the malicious version could be distributed instead, but a collision attack like this would require the package maintainer's cooperation, so while not impossible it seems less likely (and you're trusting the package maintainer quite a bit already anyway).


Should I change the password of my password manager regularly?

You should change your password when you suspect that the old one has been compromised. This is not a question of password age; thus, we are not talking about a regular password change, but about an urgent, context-dependent password change.

Apart from a situation of (suspected) compromise, changing your password does not buy you much in terms of security. On the other hand, changing your password regularly means that you will need to invest more effort in memorizing the new passwords. This may induce you into choosing passwords that are easier to remember, possibly at the expense of randomness. In that sense, regular password change can induce a decrease in security, and thus should be avoided.


Is sharing the Membership Provider with other devs a security risk?

Your question seems to be about keeping files secret for security reasons, not for intellectual property protection reasons. You should not be worried about sharing your files, especially your membership provider code. If you have custom built a membership provider, then it is especially important that you let other people review it for potential security flaws. If you have used the standard membership, such as Identity or SimpleMembership, then there is no benefit in hiding that fact.

In practical terms in any ASP.NET MVC project I have worked on, the membership aspect is so deeply coupled with the rest of the code it would be next to impossible to remove it without rendering the project useless to your collaborators, or putting an overly large integration burden onto yourself for changes that are made by them.


PCI DSS 3.0 - Is restricting SSH and/or RDP outbound required?

You could isolate the user network and production network completely from the CDE, such as so a total compromise of the non-CDE enviroment cannot in any way compromise, reduce the security, or in some other way, affect the CDE enviroment.

If you do that, then the user network and production network would be considered out of scope of PCI.

However, its good computer hygiene to still block SSH/RDP outgoing default to prevent malware from "phoning home". But by isolating the CDE from the non-CDE enviroment to gain out-of-scope for user network and production network, then you dont need to have any "strict" procedures for opening ports. Eg, you do not need to follow PCI-DSS procedures for opening ports on the non-CDE part of network.

Then you can have SSH/RDP closed, but those that need SSH/RDP for business simply need to phone call and have the port opened in front of them.

Thus you Place the CDE with its own firewall, on one public WAN internet Connection, and the user network/production network, on a Another WAN Connection with its own firewall. This will make the CDE network and user/production network, to be completely separate.

No part of the user or production network may be authorized to pass the CDE firewall, Everything Before CDE firewall should be treated as WAN when talking about PCI-DSS compliance.

Note that the CDE Firewall also needs to be put inside the physical bounds of the CDE PCI-DSS enviroment aswell, so the CDE firewall itself gains the same physical security as the CDE enviroment.

Note that the "moonlighting" part is not something defined by PCI-DSS. PCI-DSS is about protecting your customers, not yourself. By gaining out-of-scope for your user-network and production-network, you do not need to care about protecting your customers when fiddling with the user-network and production-network, you only need to care about yourself.

Thus, if you then want to have "moonlighting" protection, its up to the Company. They dont need to Think a smallest bit about PCI-DSS when fiddling with user/production network if the CDE enviroment is properly segmented.


Which is the correct algorithm while checksumming a portion of code?

I hope you understand that this is security through obscurity and provides no meaningful level of integrity against an adversary who is attempting to modify your code in memory. For this to be effective in any way, the CPU's execution unit would have to be the one verifying the checksum, allowing modified code to simply refuse to execute. If the check is entirely in software, an attacker could quite trivially modify the checksum itself to match the modified code before it is executed.
With that said, the method to use would be a hash of some sort. There are three types of hashes:

Checksums involve the addition of a numerical representation of each component of the data, multiplied by a weight factor. Checksums are extremely fast, but are not cryptographically secure and can often miss modified data even under ideal circumstances.
An example is Fletcher-64.

Cyclic Redundancy Checks use the remainder of polynomial division of the contents as a digest. The polynomial is carefully selected to increase the chance of detecting modification. They are generally very fast, but a malicious actor can trivially "break" them.
An example is CRC32.

Cryptographically secure hash functions are much slower than the other options, but are designed to reduce the chance that two inputs with differing contents will resolve to the same digest, regardless of how they are generated. Non-collision-resistant functions can have any digest size. To be collision-resistant, they need larger digest size, such as 160 bits.
A collision-resistant example is SHA-256. A non-collision-resistant example is SipHash.

Given that you are only writing a proof of concept, you should use a simple and fast checksum or CRC. A proper implementation would use custom hardware verifying a cryptographically secure hash such as SHA-256 as part of a digitally-signed hash tree. If you have access to hardware with SSE4.2 (see page 61), you can use a hardware-accelerated implementation of CRC32c (using polynomial 0x11EDC6F41). This allows a digest to be generated using one instruction for every QWORD of data to be processed, using the crc32q instruction. Otherwise, you would want to use a very fast and extremely simple checksum such as CrapWow or Murmur. It will suffice for a proof-of-concept.


Can you encrypt a password using that password itself?

To answer your specific question, then yes, of course, you can encrypt a piece of data using another piece of data as key, even if both the data and the key happen to be identical. But what would that achieve ? Decrypting would be difficult: you need the key to decrypt, and you do not have the password until you have decrypted it...

"Self-encryption" could be viewed as a kind of hash function: a deterministic transform of some input data, in a way which can be reversed. Hashing is the proper framework for password storage (where, in fact, the password is not stored, only a password verification token). However, growing home-made hash functions is known to be hard; when cryptographers want to build a hash function, they take a lot of time because they need to be sure that the function is secure, and you cannot know that just by looking at it.

Also, secure hashing is not, by itself, sufficient. You need a SLOW and SALTED hash. This subject has been beaten to death several times on this site, see for instance this question or that one. The comprehensive answer being: use  bcrypt.


Bank asking for password for encrypted document

First and foremost: Isn't a letter that is sent by email still an email?

More importantly: this practice seems less secure than other implementations of password sharing processes, but it is probably not overwhelmingly risky to use.

If you compare this to the process that is used to send your debit/credit card + PIN to you - it is pretty much the same, but with less paper used.

Process 1:

Letter 1 is sent with a debit/credit card.
Letter 2 is sent with your PIN.

Process 2

You speak on the phone to set the password.
A letter is sent with confidential information.

The important part is, that both steps (1) are separate from the related steps (2). So if only one message is intercepted, it is useless without the other. There are certain risks involved that apply particularly for process 2. E.g. if the person you speak to, intercepts the mailthe one with the letter he/she would have both information needed. It is also relatively "easy" to record phone calls for an employee in a call center, while it is "harder" to check the contents of a sealed envelope without the recipient knowing.

The biggest risk involved is the transmission of the password. At least the call center agent knows the phone if you do have to tell them directly. If this person then intercepted the e-mail/letter, they would have all the information that is needed to get to the confidential information. The likelihood of that happening is probably relatively small though - unless you are a high priority target. If you are and this information is crucial don't do this. If you aren't, then go for it.


Chrome is telling me I am receiving a forged certificate for Gmail, is someone trying to hack me?

Try it on a non-Canary build of Chrome. Last I checked, Canary builds aren't even tested before release so you can't come to any any concrete conclusions unless you use one of the release branches.

As for making the same https connection using Firefox and Safari, I think you have disproved covered the vast majority of security failure possibilities. But the error from Chrome is from a feature that Firefox and Safari do not provide. Thus a good final step would be to get the Chrome stable version to answer your question.

Since Canary builds are so volatile, I think that getting a yes or no answer from us to whether it is a bug is unlikely, unless someone else who runs Canary happened to re-create the problem. You need to use one of the release branches of Chrome.

Edit: According to other comments posted on your question (which have since been deleted), it looks like a temporary Canary problem, switching off of Canary will most likely fix it, and, if you are on an untrusted WiFi, that would be a safer than ignoring the error.


How does Ransomware use vssadmin.exe with admin privileges

There are many process injection techniques, there is no standard way used in all ransomware.

Some of these techniques:

Classic Dll Injection Via Createremotethread And Loadlibrary.
Portable Executable Injection (Pe Injection) Process Hollowing (A.K.A
Process Replacement And Runpe)
Thread Execution Hijacking (A.K.A    Suspend, Inject, And Resume
(Sir))
Hook Injection Via Setwindowshookex
Injection And Persistence Via Registry Modificatio (E.G.
Appinit_Dlls, Appcertdlls, Ifeo)
Apc Injection And Atombombing
Extra Window Memory Injection (Ewmi) Via Setwindowlong
Injection    Using Shims Iat Hooking And Inline Hooking (A.K.A
Userland Rootkits)

The following link describes all of the above techniques.


Is it safe to attach a potentially malicious hard drive to a Solaris machine?

An adversary who is aware of your procedure could manipulate the hardware to exploit the tools you are using. The filesystem driver itself and any automatically executed programs after mounting the drive can be attractive candidates for this.

However, this would be a rather obscure attack. Since you only look at the partition table and the format tool likely also considers inconsistent drive data, your risk is probably rather low. As long as you don't mount partitions from unknown sources, there should be no problem.

Another even more obscure attack would be to manipulate the hard drive such that it uses DMA to compromise your system. This is even less likely and probably what you mean by "computer inside the hard drive".


As @schroeder mentioned in the comment, the design goal of a product like BitLocker is to prevent exactly what you are asking.

It is impossible to decrypt an encrypted drive without a key? No - you can exhaustively search the entire key space until you locate one that works - if you can tell that is the case.

Is it feasible to decrypt an encrypted drive without a key within a reasonable amount of time and effort? No, it could take millenia to complete such a task.

Is there any way to crack a Bitlocker drive?


What is ("ASCII" redundancy) which is said to be required to retrieve the original plain text in 2 times pad?

It is not really the redundancy of ASCII, but the redundancy of that which is encoded with ASCII. Namely, you use ASCII because you encode sequences of characters, and you use characters because you want the data to be perceptible by human eyes and brains. So the data is text or something close enough (e.g. XML). Some characters will be more common than others. Some patterns will be used.

The whole idea of a reused one-time pad is that it transports information from one plaintext to the other: if you know 'A xor P' and 'B xor P' (A and B being the plaintext bytes, P the pad), then you can compute 'A xor B' by xoring the two values together. Then every bit of information you learn about A yields the corresponding information on B. For instance, if A is some XML text and you have already ascertained that some plaintext bytes are "<config" then you can guess that the next byte of A will probably be a ">", a space, or a "u". These are three possible plaintext bytes, from which you can immediately deduce the only three possible plaintext bytes at the same position for B. Depending on what you know of B, you can prune out values which "make no sense", and thus know the byte value for A, and so on.

When breaking the infamous two-times pad, you just keep on propagating information from one plaintext to the other, and back.

ASCII already says quite a lot, because valid ASCII values are in the 0 to 127 range, but in "normal" text, a lot won't appear: in the 0 to 31 range, only 9 (tab), 10 (lf) and 13 (cr) will be encountered in practice.


Can a CSR be created in OpenSSL with SHA2?

You can add, for example the -sha256 flag to the OpenSSL command line when generating the CSR.  I don't believe any CA will change how they sign your CSR based on this, and it certainly won't affect the certificate chain.  They're not resigning the cert chain for each key, the only signature operation they do is on your CSR itself.  Any intermediate/root CAs provided will be exactly the same for all customers.


Apache 2.2 mod_ssl configuration Forward Secrecy/BREACH/BEAST/CRIME

Here are some hints regarding where to find more information on SSL-setups and attack-mitigations: Ciphers depend on the OpenSSL version running on your server:

SSL Labs: Deploying Forward Secrecy
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
Mozilla: Security/Server Side TLS
SSL - Attack - mitigations


Is it always safe (virus/malware/spyware) to download video/music files (torrent, lbry)?

The simple fact is that you can almost never completely trust a file you downloaded from unknown sources. Even if the file is not an executable as verified by LBRY, it could contain a specific formatting exploit to affect the playback application you are using to listen or view the file. E.g. See VNC exploits on Metasploit. If the application you are using to playback the file is vulnerable, an attacker can still gain access to your system.

Making use of a sandboxed system will keep you safe but as you mentioned, it comes with additional hassle.


Sql Injection and no priviliges to write files

You need to escalate privilige to write file.


The term has two meanings.

In it's original meaning in the book, it is a malware program that an attacker uses to replace a legitimate program - like a cuckoo laying it's eggs in another bird's nest .
More specifically, it was a replacement for atrun, which is executed every 5 minutes - meaning the attacker had to wait at most 5 minutes before his malicious code was executed. Stoll refers to this as the "hatching" of the cuckoo's egg.

From pg 123 of "The Cuckoo's Egg":

  I watched the cuckoo lay its egg: once again, he manipulated the files in my computer
  to make himself super-user. His same old trick: use the Gnu-Emacs move-mail to
  substitute his tainted program for the system's atrun file. Five minutes later,
  shazam! He was system manager.

The other meaning of the term is a music file that has a contents other than it's title suggests, put on file-sharing networks in an effort to combat piracy. See the footnote in the Wikipedia article about Stoll's book.

In both meanings, it is a file whose contents is different from what is expected.


What you are trying to accomplish does not work based on the JWT specification. Let's focus on the relevant part (taken from JWT.io), the scope of the signature:

  To create the signature part you have to take the encoded header, the
  encoded payload, a secret, the algorithm specified in the header, and
  sign that.

You sign the header and the payload. According to RFC 7519, the payload contains the "exp" claim, which defines the expiration time.

This means, if you want to refresh the token, you have to change the expiration time. This changes a value that is signed. Therefore, the signature must also change, otherwise it doesn't validate the rest of the token.

Long story short, you cannot change the expiration time without changing the signature

EDIT:
Based on the source of this method, one crucial information was missing in the original question.

My answer above is still correct, if you implement JWT expiration with the "exp" claim. The linked method sets the "exp" to a full day (see chapter "Other Important JWT Payload Content"), thereby avoiding an actual token timeout. When the token (containing header and payload) gets refreshed, they do not change the content at all, but they only change the expiration date of the cookie. That way, the token stays the same and the signature stays valid.

So your issue is setting the "exp" claim to 1 hour instead of 1 day as suggested in the article.


How can I check password strength client-side?

You can use zxcvbn, which is a JavaScript library that checks password strength.

Alternatively, the HaveIBeenPwned API takes an interesting approach to check passwords without sending the password to the server:

Take a SHA1 hash of the password.
Truncate it to five characters.
Send this to the server.
The server returns the full SHA1 hashes of all known (insecure) passwords with these five characters at the start of their hash.
The client checks whether the password hash is in this list.

This way, you don't submit the whole password but the client also doesn't need to retrieve the whole password database.


What kinds of encryption are _not_ breakable via Quantum Computers?

As usual, journalism talking about technical subjects tends to be fuzzy about details...

Assuming that a true Quantum Computer can be built, then:

RSA, and other algorithms which rely on the hardness of integer factorization (e.g. Rabin), are toast. Shor's algorithm factors big integers very efficiently.
DSA, Diffie-Hellman ElGamal, and other algorithms which rely on the hardness of discrete logarithm, are equally broken. A variant of Shor's algorithm also applies. Note that this is true for every group, so elliptic curve variants of these algorithms fare no better.
Symmetric encryption is weakened; namely, a quantum computer can search through a space of size 2n in time 2n/2. This means that a 128-bit AES key would be demoted back to the strength of a 64-bit key -- however, note that these are 264 quantum-computing operations; you cannot apply figures from studies with FPGA and GPU and blindly assume that if a quantum computer can be built at all, it can be built and operated cheaply.
Similarly, hash function resistance to various kind of attacks would be similarly reduced. Roughly speaking, a hash function with an output of n bits would resist preimages with strength 2n/2 and collisions up to 2n/3 (figures with classical computers being 2n and 2n/2, respectively). SHA-256 would still be as strong against collisions as a 170-bit hash function nowadays, i.e. better than a "perfect SHA-1".

So symmetric cryptography would not be severely damaged if a quantum computer turned out to be built. Even if it could be built very cheaply actual symmetric encryption and hash function algorithms would still offer a very fair bit of resistance. For asymmetric encryption, though, that would mean trouble. We nonetheless know of several asymmetric algorithms for which no efficient QC-based attack is known, in particular algorithms based on lattice reduction (e.g. NTRU), and the venerable McEliece encryption. These algorithms are not very popular nowadays, for a variety of reasons (early versions of NTRU turned out to be weak; there are patents; McEliece's public keys are huge; and so on), but some would still be acceptable.

Study of cryptography under the assumption that efficient quantum computers can be built is called post-quantum cryptography.

Personally I don't believe that a meagre 80 millions dollars budget would get the NSA far. IBM has been working on that subject for decades and spent a lot more than that, and their best prototypes are not amazing. It is highly plausible that NSA has spent some dollars on the idea of quantum computing; after all, that's their job, and it would be a scandal if taxpayer money did not go into that kind of research. But there is a difference between searching and finding...