Turn exisiting USB drive into hardware encrypted drive?

Why not use BitLocker? BitLocker To Go is exactly what you need. Allows for quick and dirty encryption on removable drives. Instructions included below.

http://infosec.nmsu.edu/instructions-guides/how-to-enable-bitlocker-to-go-for-external-hard-drives-and-usb-flash-drives/


Yes, it is still a problem. Printers are the first big "IoT" device and the problems that have plagued printers plague every other IoT device today.

And the way to mitigate problems are similar:

patch
configure
isolate

Make sure the IoT device is fully patched (and because they may not tell you they need updating, you might have to manually check)

Ensure that the configuration of the IoT device is as secure as possible as the device permits (default passwords, strong passwords, turn off unused services, etc.)

Isolate the device in its own network and lockdown the traffic. Consider blocking all traffic initiated by the device, blocking internet access.

These are things that you can do either in a corporate setting or a home setting.


It doesn't make a difference if used correctly.

The first version is standard though. Single quotes are less often used around HTML attribute values, so you need to be a bit more careful when using various functions meant to protect against XSS, as they may not necessarily take this case into consideration.

htmlspecialchars for example does not encode ' by default, you need to specifically set ENT_QUOTES. Any custom function your project or framework may use may have the same problem.


For the rest use formula:

f(x)=(5*x) mod 9

For example if you have f(5)=7 the next step is

f(x)=(5*7) mod 9 = 35 mod 9 = 8

and so on


Is a parcel letterbox based on a tracking code secure?

I would strongly consider encrypting the barcode lists on your server and on your letterbox, if either of these devices have vulnerabilities that allow an attacker to get that list, they essentially have a list of access tokens and your security is comprised.

You should secure the communication between your client and server and ensure your device checks certificates when it retrieves the new barcodes. Attack vectors here being man in the middle sniffing of access tokens (your barcodes) and illicit devices sending you fake tokens if you don't validate the sender. You could consider digitally signing the updates and validating the signature

I'm also thinking of barcode validation, it seems theoretically possible that a sql injection attack could happen with a malicious barcode. Santisation of input, parameterised procedures etc will help mitigate but you may want to research further.

You also need to revoke tokens one they are used. When your delivery driver figures out he can photocopy a barcode and reuse it, security is compromised.

I'm not sure how many possible barcode combinations there are,  I imagine it depends on the specific scheme, but you should probably change your own tokens regularly and consider 2FA.

Hope that helps.


It is for backwards compatibility with normal DES. If you use the same key for the first two operations, they cancel out and you are left with a ciphertext encrypted under a single DES key.

Decrypt is not the same as encrypt. Symmetric refers to the fact that both use the same key but the actual steps are effectively reversed.


When you accept to run software from anyone, including the game itself, you are already trusting that software. If the software publishers are intent on attacking your PC, then they can do it from the main game binary; they don't need to use Game Guard for that. As a corollary, refusing to run Game Guard will not protect you from that company.

One case could be made that Game Guard, being used by many games, becomes a higher-value target: successfully planting a backdoor in Game Guard would give access to a lot more machines than a backdoor in just one game. In that respect, Game Guard comes close to operating systems.

How dangerous Windows is ? (or Linux, or MacOS X,...)


You are mixing the "session" as the current identifier of your browser/you in a web application, and the session of the user in her computer, meaning all the tabs opened.

Now for your other questions :

  If I stop the computer with my web-app, and then start it again before
  the timeout set on the session on the server expires, then anybody
  that starts the computer and clicks "restore session" could continue
  in my web-app where I left off.

It depends on how you defined the session duration & expiration. You can define the session to expire when the browser is closed. If done so, the user won't be able to restore the session when he'll reopen it's browser. Now if you defined a duration instead, it depends if the session will have been expired or not.

  Is there any way to kill the sessions after I close the browser like in IE and Google Chrome?

Like I said, just define no expiration date for the cookie session (if you use it like this) to expire when the browser is closed and it will be good.(see Wikipedia for that.)


Account switcher in browser implementation and secure design

I'm not sure how it works in your specific case but you are asking about a more general case anyway.
The basic problem you seem to have that you could not understand how a single cookie/token could be used with multiple users. But a cookie/token does not need to contain any actual user related information in the first place, it can just be a key which points to these information at the server side. And which information are currently associated with this key are fully controlled by the server.
A simple implementation could thus keep the current session state (which includes which users are logged in) at the server side and only associate it with the current/token. When receiving the cookie/token the server simply looks up the associated information, i.e. if it is valid at all and which user is currently associated with it. When switching the user simply different information would be associated with the same cookie/token.


Nmap not following redirect when using "http-title" script

It has to do with the kind of redirect.

Here is the code: https://github.com/nmap/nmap/blob/master/scripts/http-title.nse

  -- check for a redirect
  if resp.location then
    redirect_url = resp.location[#resp.location]
    if resp.status and tostring( resp.status ):match( "30%d" ) then
      return {redirect_url = redirect_url}, ("Did not follow redirect to %s"):format( redirect_url )
    end
  end

If the status code is anything in the HTTP 300 range, then ""Did not follow redirect to ..."

So, basically, it is hardcoded to not follow redirects.

I found another NSE script called showHTMLTitle.nse to allow one redirect.


How does the browser/app trust the Root CA when the installed Root CA certificate expired?

The installed Root CA certificate also has an expired time, it's 20 years long. When it expired, how does the browser / OS System verify the Root CA certificate anymore?

You don't.

  We will just pray the browser will get new Root CA certificate installed into our system before it expires?

It will get updated as part of standard software updates, probably long before it expires.


Security evaluation: what is there apart from common criteria?

I'm a CC evaluator with CGI Canada. Hopefully I can answer some of your questions.

I'm not entirely certain that CC is the most obvious choice. Common Criteria -- at least for the Canadian scheme -- cannot simply be purchased (this might be different in other jurisdictions, but I think France is similar). The product has to support the security posture of the Cdn gov't. What this means is that if similar products are not in use in the Cdn gov't, critical infrastructure, and associated services, and is not seen as being one of a handful of emerging technologies that will be implemented, then it is unlikely you could even start a CC program.

With that said, let's assume that you have a product that could go into the CC program.  There's no stipulation that states the product has to be finalized before the CC program can start. There is only the stipulation that the product not change in specifications while the  evaluation is going on.  It is entirely common for a developer to be actively building a product while undergoing an evaluation.  This just-in-time evaluation methodology is very efficient and popular.

As for CC focusing more on methodology more than actual "security" keep in mind that infosec is more than just penetration testing.  It is a comprehensive examination of all of the tenants that are part of bringing a product through the lifecycle. This includes physical and logical security of the development environment, supply-chain security, HR hiring practices, development methodology, and obviously security evaluations of the product itself including a deep understanding of the design, architecture, functional specs, and -- in some cases -- a source code review.

In this regards, CC is similar to other evaluations.  Take a look at PCI-DSS (credit card handling): they have physical security, development processes, HR hiring, etc. in there as well.

I understand you want to stand out, and there are certain other evaluations that may be of more interest to you such as industry-based certifications (almost every industry has one), a recognized penetration test (if this is where you think you are weak), and even independent source code reviews.


File system encryption with plausible deniability

With VeraCrypt's Hidden Volumes there is plausible deniability of your actually protected data. But you can apparently only have a hidden volume within another veracrypt volume. So the attacker will know that you are using encryption, but he will not know if you have a hidden volume. You could maybe even maintain several hidden volumes, so you could pretent to given them the password to your hidden volume but it will not be the correct one.

Otherwise, you could have one unencrypted partition on your hard drive which you boot from normally. And then have some other seemingly unused partitions which are in fact encrypted VeraCrypt volumes. But I guess such unused partitions may already be suspicious to the attacker.

Or have your encrypted volume on an external drive which you pretend to have been recently erased. I am not sure, though, if the header data of encrypted drives will give aways something about the fact that they are encrypted.

UPDATE: If you are looking for methods to hide information (encrypted or not) within non-encrypted data, maybe digital watermarking has some interesting approaches.


To exploit this flaw, the attacker would need to manipulate the user’s cookie. And this is only possible if he is able to exploit another vulnerability that allows him to set the cookie with the XSS payload as one can only set cookies within the domain the Set-Cookie originated from:

  The user agent will reject cookies unless the Domain attribute
     specifies a scope for the cookie that would include the origin
     server.  For example, the user agent will accept a cookie with a
     Domain attribute of "example.com" or of "foo.example.com" from
     foo.example.com, but the user agent will not accept a cookie with a
     Domain attribute of "bar.example.com" or of "baz.foo.example.com".

And besides compromising the server, there are two possible attack vectors for manipulating the cookie value: Either the attacker manages to inject the exploit into the value that gets set as the cookie value by the site author’s script, e.g., some user provided values are used for the cookie value. Or the attacker has access to a sub-domain and he is able to set a cookie for the super-domain in which vulnerable script that prints the cookie value resides. Both vectors can be executed by using Cross-Site Request Forgery.


Is including the data scheme in your Content Security Policy safe?

The note on whitelisting the data protocol which is referenced says

  data: Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.

This is not in a part specific to the risks of data uris in images, and I have not seen any substantiative evidence that data uris in images can execute code in a modern browser any respect, nevermind XSS a page.

In certain contexts, an SVG image can execute Javascript code, but these are either child contexts such as <iframe>, <object> or <embed> elements, or a direct part of the host DOM i.e. <svg> elements.

MDN calls out explicitly that <img> embedded SVGs cannot execute Javascript, along with some other security restrictions, saying

  JavaScript is disabled.
  External resources (e.g. images, stylesheets) cannot be loaded, though they can be used if inlined through data: URIs.
  :visited-link styles aren't rendered.
  Platform-native widget styling (based on OS theme) is disabled.

It doesn't appear to be possible to specify a MIME as part of the data: protocol whitelisting statement as suggested as a possible mitigation. The only content security policy directive I've seen able to restrict MIME type is plugin-types, which restricts only for <object> and <embed> (see general CSP docs).

I will agree with the accepted answer in the respect that if you don't have to use data-uris, and can do so with little pain, it's easier to just keep your CSP and not use them. However, if you're working with images at all, that is usually a huge pain.


What differentiates a CA cert from a server cert?

Whether or not a certificate can be used to sign another certificate is defined by the basic constraints field of the certificate. When you submit a CSR to a CA, the certificate returned by the CA should specify that the certificate cannot be used to sign other certificates in the basic constraints field.
Otherwise, this would open the door to anyone being able to create a fake certificate for any site. For example, I could create a CSR for mysite.com, get the certificate signed by a CA like VeriSign, then create a CSR for www.paypal.com and use the certificate for mysite.com to sign the certificate for www.paypal.com. Then, I would have a valid certificate for www.paypal.com. But, I'm not paypal.com.
Notwithstanding, many early SSL implementations in early browsers and even some early versions of OpenSSL did not check the basic constraints field of the certificates in a certificate chain, so this was a vulnerability that could be exploited. Security researcher Moxie Marlenspike was active in bringing this to the public's attention which forced browser makers to fix this. See http://www.thoughtcrime.org/ie-ssl-chain.txt here for more info.


In theory it is entirely possible that digitising paper documents could improve their overall security, but it depends on the specifics and how well protected/controlled the current environment is, and whether that will be improved once the new project is rolled out.

If you're looking to make this case, you could look at your organisations current risk register to see if there is anything there relating to storage and management of physical documents and then assess whether your project will address these risks.  If it will then you could easily claim that the project is in-line with the goals of ISO27001.

Of course that could be slightly disingenuous as it doesn't take account of new risks being introduced by the project, but then hopefully you'll already have those under control in the project risk register.


Ideally, you should not do any personal stuff like browsing, gaming, social media networking etc. on the same machine/workstation/tablet that you use for work.

This practice has contributed to many corporate breaches, here is the latest example:
https://castbox.fm/episode/Job-seeker-exposes-banking-network-to-Lazurus-Group-%E2%80%94-Research-Saturday-id101971-id134807630?country=us

  Today I saw that my browsing and history from my computer back home came up in Chrome on the tablet.

That's because you're signed in on both devices with the same Google account and have the Sync turned on. You can turn the sync feature off on your tablet and put 2FA on your account .. or better if make a new Gmail account altogether for the tablet.

  Can my job see what am browsing at home just because am logged in on the tablet? Or is this information encrypted from Google?

Technically no, as long as you don't hand over the password or unless you are using a Gsuite account on the tablet, your company admin can remotely wipe the device, set certain policies and even reset your corporate email password to get access to the history. So generally, it is a good practice to turn your history/location/voice tracking off.

But you have to take into consideration another aspect: You agree to submit to the information security policy of your company if you use your personal device at work, so beware, even if it is your personal device, locked with the password that only you know, your employer can ask you to hand over the password in case of any cybersecurity incident where the investigation of your machines might be required.

Stay paranoid!


Trend Micro are a fairly big player in security (well at least I have heard of them).

One of their products is a browser toolbar to warn users of malicious websites. I agree with your guess, that they are fetching pages that their toolbar has seen their users fetch, so they can decide whether it is malicious.

There is a little info on the Trend Micro spider here: http://www.webmasterworld.com/search_engine_spiders/3657953.htm

Ideally they would only replay GET requests, and GET requests should be idempotent (have no side-effects). If your user data is getting changed as the result of a GET request, then I would recommend changing that to a POST. Not only the Trend Micro bot, but any robot or search engine spider might come along and do a GET on any link and cause an unwanted result for you.


Why do browsers warn about mixed content for images?

I would assume your reasoning is something like, "If the person constructing the page chose to send some of its images insecurely, then the browser should respect that this decision was done for a reason and allow it without a warning. The page is as secure as the entity providing it wanted it to be."

By contrast, the reasoning of the browser developers is something like, "We are putting a secure icon on the page as seen by the user and the user should be able to assume that means the whole page is secure. If some part of it isn't, the user deserves to know that."

Both arguments are valid, they're just different interpretations of what it means for a web page to be secure.

There are specific risks with images too. The image is requested in the clear using the HTTP protocol. This discloses any information in the URL or headers. The most serious threat is that the image could contain instructions or information that the user would assume securely originated from the site the user chose. This could be used for phishing attacks.


How can I use X.509 cross signing to replace a CA?

These answers might be helpful:

https://stackoverflow.com/a/33365131/1907046
How to properly create and use cross-signed CAs and certificates

Alright, so the idea would be to place the cross-certs into the trust stores of your clients so that during cert validation they can path-build from the CA they don't trust to the one they do.

Your test-scenario is that you have an end-entity cert issued by ca-A, and a client verifier who only trusts ca-B.  You also have a ca-A-by-B cross-cert that you can give to the client so that it can path-build between the two CAs.  I believe the correct openssl command-line incantation to simulate that would be:

-CAfile ca-B.pem so that ca-B is "in the trust store".
-untrusted ca-A-by-B.pem so that the verifier is aware that it can use that cert for path-building, but doesn't consider it a trusted root.
< (cat ca-A.pem child.pem) simulate receiving a cert-bundle containing the end-entity cert and its issuer (ca-A).

all together:

openssl verify -verbose -CAfile ca-B.pem -untrusted ca-A-by-B.pem < (cat ca-A.pem child.pem)

I haven't actually tried this cause I'm too lazy to generate test certs, but let me know if it helps (or if I need to make corrections).


The simple answer is that if somebody is doing obvious probing, drop them. phpMyAdmin, for example, is a tell-tale that is never legitimately requested unless you installed it for your own private use. I suggest a 15 minute "drop all packets" response, or ICMP unreachable by admin response if you feel particularly verbose. You can trigger this with Apache rewrite rules, security modules, fail2ban and regular logs, or an application firewall system.

I personally use type 3, code 13 for misbehaving NTP clients (just the application, not taking out the whole host), 9 for killing them at the network, and 10 if the system in question only has 1 IP. Not many folks pay attention to those, but I consider them my "Bad Internet Citizen" flags.


Hardware / firmware backdoors : TPM as a security risk - How to turn it into security advantage?

While we aim tech to solve all problems for us, in security, trust is an important contributing factor.

So the short answer is: When hardware, firmware (and why not chip-level?) backdoors are part of your threat model, TPM is just not good enough.

I'm skipping a longer answer coz your question already includes the scenarios to justify this answer. :)

It is a problem mainly because it is designed to inspire trust and thus lower your guard. In practice (as commented by @eckes) other risks are much bigger.

Edit based on the comments:
Scenario: We can't trust signed updates by Microsoft (or any other OS publisher.

Yes TPM can be used to "sign our own bootloader" to counter the problem. As you already pointed out ("ignore the fact that..."), we need to assume trust of already installed components or accept the risk as you have pointed out ("ignore the fact of...").

IMHO, when you don't trust a vendor, you can't use any of the components (not just those protected by the TPM) supplied by that vendor without extensive verification. Further, you have to disable updates, or subject every update to the same level of verification.


Why does WannaCry use different AES keys to encrypt different files on host?

The criminals who created the ransomware can't be consulted for comment.  But we can look at the tradeoffs involved.

By using different keys for different files it allows the attackers to decrypt the files on a file-by-file basis, without providing the key to ALL the files.

I don't have a reference for this right now, but I recall that the ransomware perpetrators will offer to decrypt one file as a demonstration that they have the keys (one might call this "good faith").  They can only do this if each file is encrypted with a different password.  If all files were encrypted with the same password, decrypting one file would allow ALL files to be decryped.


True or False: HSTS is absolutely useless against MITM attacks

Statement 1: There should be no header for an attacker to strip since sending it over HTTP is useless. No idea why someone would send it over HTTP. And if the attacker has certificates that the client trust so a HTTPS connection will be established, then HTTPS won't bother the attacker.
A connection over HTTP is still vulnerable, HSTS won't change this. It will transparently switch from HTTP to HTTPS if a valid HSTS entry exists.

Statement 2: Again, a browsers should only act on HSTS headers sent over a HTTPS connection. If the attacker can send that header (s)he won't be bothered by HTTPS.

Anyway, Defense in Depth! Which is why I do not think that HSTS is useless. If you immediately upgrade every HTTP connection to an HTTPS connection using redirects your users can be vulnerable a lot over the course of a year!
Compare that to the initial connection when using HSTS and a browser that supports it!


is possible someone break the algorythm of my dice game with hashes

"Revealing a hash beforehand" does not mean the algorithm is broken.  We call this a "commitment," and its a well recognized tool.  However, that doesn't mean that an algorithm which uses commitments is not also broken.  You have to analyze the algorithm.

As an extreme example, if you were committing to a 6 sided die roll, and didn't use a nonce, then there's only 6 possible commitments, and its trivial to see what was committed.


Processor microcode manipulation to change opcodes?

Although modern x86 processors allow for runtime microcode upload, the format is model-specific, undocumented, and controlled by checksums and possibly signatures. Also, the scope of microcode is somewhat limited nowadays, because most instructions are hardwired. See this answer for some details. Modern operating systems upload microcode blocks upon boot, but these blocks are provided by the CPU vendors themselves for bugfixing purposes.

(Note that microcode which is uploaded is kept in an internal dedicated RAM block, which is not Flash or EEPROM; it is lost when power is cut.)

Update: there seems to be some misconceptions and/or terminology confusion about what microcode is and what it can do, so here are some longer explanations.

In the days of the first microprocessors, transistors were expensive: they used a lot of silicon area, which is the scarce resource in chip foundries (the larger a chip is, the higher the failure rate, because each dust particle at the wrong place makes the whole chip inoperative). So the chip designers had to resort to many tricks, one of them being microcode. The architecture of a chip of that era would look like this:

(this image was shamelessly plundered from this site). The CPU is segmented into many individual units linked together through data buses. Let's see what a fictional "add B, C" instruction would entail (addition of the contents of register B and register C, result to be stored back in B):

The register bank must put the contents of the B register on the internal data bus. At the end of the same cycle, the "TEMP" storage unit should read the value from the data bus and store it.
The register bank must put the contents of the C register on the internal data bus. At the end of the same cycle, the "A" storage unit should read the value from the data bus and store it.
The Arithmetic and Logic Unit (ALU) should read its two inputs (which are TEMP and A) and compute an addition. The result will be available on its output at the next cycle on the bus.
The register bank must read the byte on the internal data bus, and store it into the B register.

The whole process would take a whooping four clock cycles. Each unit in the CPU must receive its specific orders in due sequence. The control unit, which dispatches the activation signals to each CPU unit, must "know" all the sequences for all the instruction. This is where microcode intervenes. Microcode is a representation, as bit words, of elementary steps in this process. Each CPU unit would have a few reserved bits in each microcode. For instance, bits 0 to 3 in each word would be for the register bank, encoding the register which is to be operated, and whether the operation is a read or a write; bits 4 to 6 would be for the ALU, telling it which arithmetic or logic operation it must perform.

With microcode, the control logic becomes a rather simple circuit: it consists of a pointer in the microcode (which is a ROM block); at each cycle, the control unit reads the next microcode word, and sends to each CPU unit, on dedicated wires, its microcode bits. The instruction decoder is then a map from opcodes (the "machine code instructions" which the programmer sees, and are stored in RAM) into offsets in the microcode block: the decoder sets the microcode pointer to the first microcode word for the sequence which implements the opcode.

One description of this process is that the CPU really processes microcode; and the microcode implements an emulator for the actual opcodes which the programmer thinks of as "machine code".

ROM is compact: each ROM bit takes about the same size, or even slightly less, than one transistor. This allowed the CPU designers to store a lot of complex distinct behaviours in a small silicon space. Thus, the highly venerable Motorola 68000 CPU, core processor of the Atari ST, Amiga and Sega Megadrive, could fit in about 40000 transistor-equivalent space, about a third of which consisting of microcode; in that tiny area, it could host fifteen 32-bit registers, and implement a whole paraphernalia of addressing modes for which is was famous. The opcodes were reasonably compact (thus saving RAM); microcode words are larger, but invisible from the outside.

All this changed with the advent of the RISC processors. RISC comes from the realization that while microcode allows for opcodes with complex behaviour, it also implies a lot of overhead in instruction decoding. As we saw above, a simple addition would take several clock cycles. On the other hand, programmers of that time (late 1980s) would increasingly shun assembly, preferring the use of compilers. A compiler translates some programming language into a sequence of opcodes. It so happens that compilers use relatively simple opcodes; opcodes with complex behaviour are hard to integrate into the logic of a compiler. So the net result was that microcode implied overhead, thus execution inefficiency, for the sake of complex opcodes which the programmers did not use !

RISC is, simply put, the suppression of the microcode-in-CPU. The opcodes which the programmer (or the compiler) sees are the microcode, or close enough. This means that RISC opcodes are larger (typically 32 bits per opcode, as in the original ARM, Sparc, Mips, Alpha and PowerPC processors) with a more regular encoding. A RISC CPU can then process one instruction per cycle. Of course, instructions do less things than their CISC counterparts ("CISC" is what non-RISC processors do, like the 68000).

Therefore, if you want to program in microcode, use a RISC processor. In a true RISC processor, there is no microcode stricto sensu; there are opcodes which are translated with a 1-to-1 correspondence into the activation bits for all the CPU units. This gives the compiler more options to optimize code, while saving space in the CPU. The first ARM used only 30000 transistors, less than the 68000, while providing substantially more computing power for the same clock frequency. The price to pay was larger code, but RAM was increasingly cheaper at that time (that's when computer RAM size began to be counted in megabytes instead of mere kilobytes).

Then things changed again by becoming more confused. RISC did not kill off the CISC processors. It turned out that backward compatibility is an extremely strong force in the computing industry. This is why modern x86 processors (like Intel i7 or even newer) are still able to run code designed for the 8086 of the late 1970s. So x86 processors have to implement opcodes with complex behaviours. The result is that modern processors have an instruction decoder which segregates opcodes into two categories:

The usual, simple opcodes which compilers use are executed RISC-like, "hardwired" into fixed behaviours. Additions, multiplications, memory accesses, control flow opcodes... are all handled that way.
The unusual, complex opcodes kept around for compatibility are interpreted with microcode, which is limited to a subset of the units in the CPU so as not to interfere and induce latency in the processing of the simple opcodes. An example of a microcoded instruction in a modern x86 is fsin, which computes the sine function on a floating-point operand.

Since transistors have shrunk a lot (a quad-core i7 from 2008 uses 731 millions of transistors), it became quite tolerable to replace the ROM block for microcode with a RAM block. That RAM block is still internal to the CPU, inaccessible from user code, but it can be updated. After all, microcode is a kind of software, so it has bugs. CPU vendors publish updates for the microcode of their CPU. Such an update can be uploaded by the operating system using some specific opcodes (this requires kernel-level privileges). Since we are talking about RAM, this is not permanent, and must be performed again after each boot.

The contents of these microcode updates are not documented at all; they are very specific to the CPU exact model, and there is no standard. Moreover, there are checksums which are believed to be MAC or possibly even digital signatures: vendors want to keep a tight control of what enters the microcode area. It is conceivable that maliciously crafted microcode could damage the CPU by triggering "short circuits" within the CPU.

Summary: microcode is not as awesome as what it is often cracked up to be. Right now, microcode hacking is a closed area; CPU vendors reserve it for themselves. But even if you could write your own microcode, you would probably be disappointed: in modern CPU, microcode impacts only peripheral units of the CPU.

As for the initial question, an "obscure opcode behaviour" implemented in microcode would not be practically different from a custom virtual machine emulator, like what @Christian links to. It would be "security through obscurity" at its finest, i.e. not very fine. Such things are vulnerable to reverse engineering.

If the fabled microcode could implement a complete decryption engine with a tamper resistant storage area for keys, then you could have a really robust anti-reverse-engineering solution. But microcode cannot do that. This requires some more hardware. The Cell CPU can do that; it has been used in the Sony PS3 (Sony botched it in other areas, though -- the CPU is not alone in the system and cannot ensure total security by itself).


Why can't websockets support custom headers?

Why doesn't websockets support custom headers? It's unlikely to be an oversight ...

I agree that this looks like an oversight.

This actually does not surprise me since in my opinion the implementation of WebSockets inside the browser was not well-thought-out in the first place. The most glaring issue is that WebSockets ignore the same origin policy or CORS restrictions, i.e. the server needs to be explicitly check the origin of the connection (Origin header) because otherwise Cross-Site WebSocket Hijacking would be possible.

This insecure-by-default design is in contrast to the secure-by-default behavior of CORS which was created a bit earlier than WebSockets. Given this obvious security problem I doubt that any security considerations played a role in not allowing custom headers as in XHR.

Note that the WebSockets protocol itself supports custom headers since it starts with a HTTP handshake similar to a normal HTTP request. It is only the browser API which is missing the ability to use custom headers.


Is it safe to use an encryption library (e.g., RNCryptor) instead of Keychain to store a user account password for an iOS app?

Rule number one with crypto systems is don't re-invent the wheel.  Yes, you could implement a secure password store with RNCryptor, but you would need an expert to audit your code to make sure the proper protocol was followed.  That could get expensive.

If what you're seeing with the iOS keychain truly is a bug, it will likely be patched.  Check out these posts to see if they might be related to your problem:

https://stackoverflow.com/questions/10536859/ios-keychain-not-retrieving-values-from-background/10583042#10583042
https://forums.developer.apple.com/thread/26168


CSRF possible if params are not passed through query string?

CSRF does not require query parameters.

In that same article you linked, under the section: "Prevention measures that do NOT work":

  Only accepting POST requests
    Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

Basically, since with CSRF you can't make any assumptions about the originating site, it might be the attacker's own site - he might simply have a regular HTML form on his site, that submits to your bank's website. When you are viewing the attacker's site, the CSRF form gets submitted to the bank... launching the attack.
No query string necessary.


PGP - 2048-bit key VS filesize of the exported key

There's a lot more in a PGP key certificate than just the key.  There's the user, the date it was created, the expiration date, the preferred algorithms, etc.

This link has some good info.


Does it increase security to hash a SHA1 hash with a common salt with SHA256 with individual salt

As far as I can tell, there should not be any reduction in security to what you're doing as long as this are only applied to the legacy passwords. New passwords and users that have logged in should just use the new hashing system without going through SHA-1 first.

Passwords migrated from the legacy system in such a way will be at least as good as the old system. The use of SHA-1 means that for users with really long, high entropy passwords, theoretically the migrated password isn't stored as securely as the same password stored only through the new system; however if the user has a really long, high entropy password, then their passwords don't need to be salted to begin with to be secure. Practically, this should be of little concern.


Does editing a file and saving it permanently overwrite it?

This depends on the specific application. Some applications will only overwrite the individual block or blocks which you have edited. Others will, more often, create a new copy of the file under a new, temporary name, then rename it, deleting the old file. This is no more "secure" than simply deleting the file directly. You would have to have an application specifically designed to overwrite the entire file.

Neither of these techniques will overwrite the entire file. In order to do that, you will need to overwrite each block in-place. This can be done with specialized tools such as shred(1). Note that modern filesystems are complex, and there can still be remnants of data left over. For example, ext4 can keep small files that fit in a single inode in the inode itself. The inode is backed up in the journal, which is not overwritten when the inode is overwritten. Filesystems that support copy-on-write such as btrfs act like SSDs in that a single write to a given block will not necessarily overwrite the original sector on the drive where it is stored. The only real solution to eliminating sensitive information is to keep it encrypted and throw away the key before deletion.

Editing in-place

A file is composed of a large number of sectors, each of a size like 512 bytes. A sector often (but not always) maps to a filesystem block, with a sector being a physical unit of storage from the storage medium hardware, and a filesystem block being a single unit of storage as seen logically by the filesystem driver. A sector write is atomic (in theory), and editing a single byte requires writing to the entire sector it is in (although the disk uses read-modify-write to ensure that other data in the sector is not lost). Editing a file in place will only result in overwriting the sectors which contain the data being modified. Assuming you are using a filesystem that does not do copy-on-write (on Linux, pretty much everything but btrfs and ZFS), this will overwrite only the specific data being edited.

A C implementation which writes a string in-place at the 1234th byte:

void edit(void)
{
    int fd = open("file.txt", O_RDWR);
    pwrite(fd, "Hello, world!", 13, 1234);

    fsync(fd);
    close(fd);
}

Atomic editing

Often, applications will edit files by creating a new file with a temporary name and populating it with the modified contents of the old file. After it has been written (and optionally synced to disk), it is renamed to the original name, resulting in the old file being deleted, but still present on the disk. This is atomic, meaning that either the file is fully edited, or not edited at all. The intention is to ensure a crashed system which only has time to do a partial write will not corrupt the target file. Renaming is (or at least is supposed to be) an atomic operation. That is, it either fully succeeds, or fails, with no in-between.

A C implementation which copies the file and writes a string at the 1234th byte:

void edit(void)
{
    int src_fd = open("file.txt", O_RDONLY);
    int dst_fd = open("file.txt.tmp", O_CREAT|O_RDWR);

    sendfile(dst_fd, src_fd, NULL, -1);
    pwrite(dst_fd, "Hello, world!", 13, 1234);

    fsync(dst_fd);
    rename("file.txt.tmp", "file.txt");

    close(src_fd);
    close(dst_fd);
}

Overwriting in-place

To overwrite an entire file, you need to open the file (without truncating it), and write non-sensitive data to it. The amount of data written should be equal to the original file size, or else it will be unnecessarily appended to. Note that this only works assuming the filesystem does not have any tricks up its sleeve that result in there being data remnants lying around.

A C implementation which overwrites an entire file with random data:

void overwrite(void)
{
    struct stat sb;

    int src_fd = open("/dev/urandom", O_RDONLY);
    int dst_fd = open("file.txt", O_WRONLY);

    fstat(dst_fd, &sb);
    sendfile(dst_fd, src_fd, NULL, sb.st_size);
    fsync(dst_fd);

    close(src_fd);
    close(dst_fd);
}


How do you validate that someone signed something with a private key

Signing is different from encryption (well, you still use encryption, but anyway)

For RSA (Thanks Michael):

To digitally sign, you make a hash of the data and then use the private key to encrypt the hash. You then send this along with the message you signed.

The recipient can confirm it was signed by you by decrypting using the freely available public key and comparing the hash to one they generate from the message.


How secure is ssh key-based authentication

RSA keys are sufficiently secure for the foreseeable future, and 4096 bit might even be overkill.

If you're worried you could look into setting up something like fail2ban, but if you don't allow password authentication and you have RSA keys with >= 2048 bits you're fine.

I expect if you check your auth logs you'll find a lot of authentication failures from those addresses, and that's pretty normal. Right now my public facing ssh server has a 14MB auth log, with over 82,000 failed login attempts for root:

sudo grep -i root /var/log/auth.log -c
82023


If password is changed on Active Directory, can I ensure that PC must be restarted before logon with new password

I'm not sure your security expectations here are realistic.

If someone gets access to your DC in such a way that allows them to change arbitrary account passwords, then you've got plenty of bigger problems to worry about.

If they could re-boot the system in order to force their password change to take effect (after which point, your hypothetical additional security measures take effect), then they either have:

1.) Remote login access to the system, which means that they don't need to reboot the system for this purpose because they're already on it.

or

2.) Physical access to the system, which pretty much bypasses any additional logical security you have in place, short of hard drive encryption.

Let's say, for the sake of argument, that they are able to re-boot the system but are still unable to log into it.  At this point, they've effectively DoSed whatever services the system provides which requires you to keep the system logged in at all times.  Perhaps this is not as significant of a breach as if they actually got logical access to the system.  But, depending on how critical those services are, it could have a significant impact on your organization.

The lesson here is to make sure your servers which require a high level of CIA (Confidentiality, Integrity, or Availability), such as systems running critical services and the domain controllers they answer to, are well secured physically, and separated from your other less-secured systems as far as possible both physically and logically.

I believe the saying goes something like:  "If you allow someone (either intentionally, or through lack of adequate security) physical access to your system, then the system is no longer yours."  The same goes especially for domain controllers.  If you allow someone to run arbitrary commands on your domain controller, then the domain is no longer yours.


Does using creating a seprate firefox profile cause a seprate security context protect against XSS and DNS Re-binding?

Each Firefox profile shares no data with the other profile, i.e. they are separate folders and no cookies, saved passwords, installed extensions etc get shared. The only thing which might shared application data outside the control of Firefox, i.e the Silverlight plugin is known to share data even between different browsers on the same system. Flash cookies etc are instead to a specific profile I think. This in effect makes using separate Firefox profiles a good way to separate sites which should never be able to interact inside the browser, like intranet sites and external sites or to protect online banking. It does not protect against DNS rebinding attacks since these are not based on interaction between two sites inside the browser.

To make sure that one does not inadvertently uses the wrong browser one could additionally setup a proxy.pac file for each of the browser profiles which restricts access further. But note that proxy.pac files work at the level of hostnames and not IP address, so it does not protect against external sites returning local IP addresses (i.e. attacker.example.com claiming to be at 127.0.0.1). To get also this problem resolved you need to use a DNS server which can filter the DNS response like dnswall. Such server also protects against DNS rebinding attacks.


Can sshd block IPs with failed attempts or is a tool like denyhosts or fail2ban necessary?

SSH can manage itself as a service, so shutting down a connection after X number of attempts is within its expected domain of control. Blocking an IP is a much bigger task, which is why things like fail2ban exist. SSH logs the failures, fail2ban reads those logs and then kicks off remediation, like blocking the IP at the firewall.

In short, SSH cannot do what you want it to do because that functionality is handled by other layers of the system.


Philosophical differences.  LibreSSL is designed under the philosophy that an SSL library should be an SSL library, and nothing more.  This means it doesn't try to implement half of libc, or provide other OS-level facilities, and it should not compensate for flaws in the OS -- the OS should be fixed instead.  A pool of high-quality entropy is one of those facilities that the OS should provide.

That said, describing RAND_bytes as "unsafe" is overstating things.  It's only unsafe under Linux under very limited conditions:

The program uses the old-fashioned fork/exec model of threading, rather than the newer pthreads model.
The program must have a structure where a grandparent process forks a parent process and exits, then the parent process forks a child process that, by chance, gets the same PID as the grandparent.  This is, to put it mildly, a highly unusual program structure.
The grandparent and grandchild processes both use LibreSSL's PRNG, while the process in between them does not.  This is again a highly unusual program structure, as a typical program will either perform SSL operations exclusively in the grandparent (connection-handling process with a group of worker threads) or in the grandchildren (process manager with a group of connection-handling threads).


I'm not a malware expert, but I know that blackhats tends to use a small spoofing technique by calling their malware a name that is used by the system, in order to not raise the user's attention. Also, all anti-viruses can be bypassed by performing different encoding methods that makes the malware undetectable. But of course, Anti-viruses companies are doing their best to protect users.

The IP that your device connected to is not connected to Microsoft. So try to make a WhoIs against the IP and contact the authorize if possible.

Also, since all package going from your device are the same and in useless pattern (such as abcdefg), I guess your device is used as a zombie for DDoS.


What information is provided when connnecting to public WiFi?

There are many methods which can help in discovering information about devices and people on the network, however it is difficult to get the exact identity of someone.

Browser Fingerprinting

Browser fingerprinting is one technique that can glean information about your device.

  Device fingerprinting or browser fingerprinting is the systematic
  collection of information about a remote device, for identification
  purposes. Client-side scripting languages allow the development of
  procedures to collect very rich fingerprints: browser and operating
  system type and version, screen resolution, architecture type, lists
  of fonts, plugins, microphone, camera, etc.

From https://amiunique.org/faq

See what a fingerprint can identify here

The public network may have a sign in page where it can see your browser fingerprint.

Although it is unlikely for a browser fingerprint to be able to identify exactly who the user is, it can show some useful information which could give a general indication of who the user could be.

Prevention

There are some methods which can be used to make it more difficult to be tracked:

Make yourself more common

By making yourself look more common your fingerprint becomes less unique and therefore you are more difficult to track.

An example of how you can do this is by using a common browser. This will make yourself fit in with everyone else and make your fingerprint less unique.

Disable JavaScript

This is a good defense tactic as it prevents websites from detecting data such as fonts and plugins. An example of a browser plugin to block JavaScript is NoScript.

Logs

The public WiFi may log their users activity which may be of use for them identifying users. Consider the following scenario:

Unusual activity from a device is detected. Logs are examined, and it is shown that the device connected to the public WiFi at 14:50. Looking over CCTV, it can be seen that there was only one person at that time using a laptop. They now know what that person looks like, their gender, etc.

Even if you aren't the only person on the network, the number of people that could be there is reduced by physical restrictions.

Prevention

This is a difficult thing to prevent, as you most likely don't have direct access to where the logs are stored.

Cookies

Cookies may also be of use to identify the user. If you are to sign into the public WiFi under your real name and then sometime later you sign in anonymously, the cookies can show that it is the same person signing in.

Prevention

This can easily be combatted by simply disabling cookies in the browser.

MAC Address

MAC addresses can be used to uniquely identify devices in a local network. Your identity could be discovered if the network owners were able to get physical access to devices on their network. However, this is a weak method since MACs can be so easily spoofed an infinite number of times.

Prevention

As already mentioned, this threat can be eliminated by spoofing your MAC address. If you wanted you could change your MAC address to a previous user on the network to make tracing your identity more difficult.

Hostnames

The hostnames of devices could identify the user behind the device. For example, iPhones default to yourName's iPhone. People may have also manually set their hostnames to include a keyword which can identify the user.

Prevention

Prevention is pretty easy: set the hostname to something that doesn't relate to you. If you wanted to make yourself being traced more difficult, you could include a fake name in the hostname.

Monitoring Traffic

This method will be able to get the most personal information about you. The websites and type of websites you visit may expose your true identity. If you log into a website which uses plaintext, your username can be viewed and identified to you. You might also be sending personal data such as photos and phone numbers which link back to you.

Prevention

You could prevent your traffic being monitored by using a VPN which would encrypt all your traffic, making it unreadable to others.

Conclusion

There are many methods which can be used to gather information regarding your identify, and it is difficult to eliminate all of these methods.

Although these techniques can gather lots of information, it would still be difficult to find the true identity of someone.


DB Security from system admin perspective

They need to have access to the servers and databases to be able to do their job. For sysadmins they would need the root account, for DBAs they would need the superuser account in the database (not sure what that user is for Oracle, but on MySQL that user is also named root).

If you don't trust them, don't employ them, or at the very least monitor them (by setting up off-site logging to a server they don't have access to). They will still be able to stop the logging (and make it look like it was accidental like network issue etc), but at least you'd have one more audit trail.

This related question on Server Fault goes into more detail about why this is impossible.


What is the "ThinkPwn" vulnerability and what does it allow attackers to do?

what this allows an attacker to do?

It allows an attacker to execute arbitrary code in System Management Mode (SMM), a highly privileged execution mode of x86 processors. This mode is transparent to the Operating System (OS) and it is more privileged than any other mode. If an attacker can execute code in SMM, it basically owns the platform/computer (more powerful than any other rootkit in the kernel of your OS).

It is worth noting that such vulnerability has a requirement: you need kernel privileges in order to trigger a System Management Interrupt (SMI), to execute the exploit.

There is two approaches for the attacker:

It can overwrite the firmware flash storage and disable some security features at boot. Then, even if you erase the content of your hard disk, or buy another one it can reinfect the OS without any problem. Furthermore, detecting or removing the malware from the firmware will be a hard task since it controls one of the early piece of code executing on the computer.
However, a measured boot using a Trusted Platform Module (TPM) chip could detect the modification of the firmware flash and that some security features are disabled at boot, because the measurements made (cryptographic hashes) are not genuine. Such detection is possible if the measured boot process is properly implemented by the vendor. The measurement process relies on a core root of trust where the first component measuring the next one is trusted. Hence, if this first component is the firmware contained in the flash, the attacker can fake the measurements without being detected.
It can be stealthy and just overwrite the code executed in SMM, located in SMRAM, without modifying the flash. This way it controls the code executed in SMM and can monitor or modify the behavior of the OS. The stealthiness comes from the fact that if the computer is rebooted, there is no traces of the attack in the flash (since everything was in RAM). Lots of computers, however, do not reboot that often (e.g. servers), hence the attacker does not need to reinfect the machine to still have control over it.


Is Firefox on Ubuntu less secured (does it not confine Flash)?

Usually Flash exploits need to be specifically targeted at an OS (Linux v.s. Windows v.s. whatever).  An attacker can choose to shove as many into one exploit, which would likely cause suspicion if my exploit crashes while exploiting, or make something reliable, I can use and re-use. This means the law of averages: "How many people use Windows, and how many use Linux. Where would my exploit yield better results?" If I am not specifically targeting you per-se.

Flash is usually used to deliver another payload. Whether or not the payload is specifically aimed at Windows, is what is relevant. Most Flash based exploits on their own (non payload deliverable) still need to be specifically targeted at you. Let's look at an advisory:

CVE-2014-8441

  Adobe Flash Player before 13.0.0.252 and 14.x and 15.x before
  15.0.0.223 on Windows and OS X and before 11.2.202.418 on Linux, Adobe AIR before 15.0.0.356, Adobe AIR SDK before 15.0.0.356, and Adobe AIR
  SDK & Compiler before 15.0.0.356 allow attackers to execute arbitrary
  code or cause a denial of service (memory corruption) via unspecified
  vectors, a different vulnerability than CVE-2014-0576, CVE-2014-0581,
  and CVE-2014-8440.

If I as an attacker tried to make an exploit to send to you, there are multiple ways to get it to you. But here are the hurdles I would face trying to exploit you.

Step 1) create shellcode to do the harm I need to do
Step 2) obfuscate this shellcode so it is not detected by AV

Before I even do this, I have an altogether different choice... Pick my target to exploit: Will I focus on Linux, or Windows?!? Because each is a different operating system, my payloads will differ.

IOW you're confusing how attackers use Flash to exploit an operating system. Flash is usually nothing more than a vehicle to deliver something more malicious.

ANALOGY

Imagine if you can a country named Chickenphobia where everyone is allergic to chickens. If anyone comes in contact with a chicken, they will become sick. Now imagine a bus, airplane, boat or truck delivering Chickens (with the intentions of making people in Chickenphobia sick) to the wrong town. The vehicles (bus, truck, boat, train, plain) are Flash. It is nothing more than a delivery mechanism.

-- END OF ANALOGY


Achieving End to End encryption with TLS

Unfortunately you'll find that this just isn't done. As you have correctly pointed out, you do not allow the client to connect all the way through using one TLS channel, so decryption at the web server, or TLS endpoint, is a given.

So what organisations do is assess the risk and then look at other security controls over the web server. These include:

Physical isolation
Logical segregation
Separated management connections
Strong authentication
Monitoring of admin access
Server hardening
etc

(There is a possible partial solution, which would be to run the webserver with encrypted RAM, encrypted disks and so on, however this leads to a serious performance impact, and still does not protect against an attacker who has gained access to the webserver.)


Any worries?

Well, It can be. Depends on how open the IP of the server is for ssh logins.
Is it available for the whole internet?

If yes it is highly vulnerable to attacks, It can be an easy victim of DDoS(or even DoS) attack. As port 22 to this IP(which is public) is open, Anybody can reach you with spoofed or even non spoofed sources.

  The Server has Fail2ban installed, and Root login disabled.

fail2ban only checks for wrong passwords, retries et al. So any body can send a flood of SYN packets to your IP and your server may get overwhelmed with those SYNs and sending them SYN/ACKs back to non-existent sources.

Some easy solutions would be:

Block them early in your network, Block them using a firewall or an inline device which can block requests from unwanted sources.
Use IPtables, Block(drop, do not reject) them using IPtables on your server itself.
If its used inside your network only bring it on a private IP

Hope this helps!


The wiki page for this has surprising amount of useful information here
Usually between 2 and 3 passes will almost guarantee the removal of data from the majority of the layers, but for some tools corrupted sectors can cause issues. Most companies will use shredding services there after to ensure there is nothing coming off of those disks, so as for re-selling them i'm not entirely sure how that will work ;).

Also to be sure you will be looking for digital forensics, there are degree programs surrounding this topic so don't expect to learn it in a day. The most common tool used is this one the sleuth kit, there are plenty of blogs around for tips and tricks when using it.
Happy hunting
edit dd the unix utility is also awesome for this sort of thing


How can I know the protocol versions supported at OpenSSL1.1.0g

The test program openssl s_server has several option to choose the SSL/TLS version, i.e. -ssl2, -ssl3, -tls1, -tls1_1, .... Starting with OpenSSL 1.1.0 the usage openssl s_server -help shows all actually supported options, i.e. -ssl3 is only shown if SSLv3 is actually supported. With earlier versions of OpenSSL the usage might show version which were not actually supported but an attempt to actually use these resulted in an error.

  Q: Is SSLv3 supported by default in OpenSSL1.1.0g? How can I know this?

Since you compile it from source you can just look at the output from config:

$ ./config
...
Configuring OpenSSL version 1.1.0g-dev (0x10100070L)
...
    no-ssl3         [default]  OPENSSL_NO_SSL3

Thus, it looks like SSLv3 is disabled by default.


What may a Hungarian employer do with the employee monitoring logs?

An employer may not access your personal email without your consent iirc. (Consult a lawyer to be sure)

However almost all of the time when these type of practices are in place there is an acceptable use policy that also points out if you are allowed to use company ict infrastructure to read your personal email, what they will be logging and what they might do with that information.

In Belgium we follow European guidelines, our law states:

An employer can not monitor your surf and email behavior, unless he advertised this up front. (Like I said, this can often be found in the AUP)
Only after the consent of the employee an employer may look up how much he's using the internet or how much emails he is sending.
The content of a sent/received email can not be read unless the employee has opened them and has given consent. There are exceptions on this (for instance when the employee goes on leave and the emails need to be forwarded to another employee)

If information wants to be used as proof in court it will have to follow the above guidelines UNLESS:

There was a court order to gather this information
There was a "higher" cause, this being: theft, corporate espionage or accessing information considered illegal by the law (child porn, warez,...)
Employers are also encouraged to create a UAP and provide a detailed and comprehensive list of rules to tell the employee, what he can and can not use the company's ICT infrastructure for. A company can always prohibit the use of company ICT infrastructure for personal use (Facebook, personal email)

Whilst he can conclude you are using his infrastructure for personal use, he may not access the content and certainly not send emails in your name.

This will probably be similar for Hungary as this law follows European guidelines. But please refer to a lawyer to confirm!

Also my advice: If you know these things are being monitored, don't use them for any personal matter.


Does KASLR really provide more security against exploits?

KASLR has gotten under heavy critic on the day it was released for Linux, and it has also been defeated on that very day. Spender at grsecurity has written a post about it (along with LWN comments) which I'll only summarize in a simplistic way. I highly encourage reading the original source.
Address Space Layout Randomisation was originally applied to complicate exploits, as we all know, by randomising the position of a lot of pointers on the stack. Defeating ASLR requires either of:

bruteforcing until you accidentally find the correct random address (which requires re-launching the app and barely ever applies to KASLR)
retrieving pointers that leak information about the memory layout

The second option is very promising for kernels: they can't have too much of a large random offset because some hardware configurations might have a limited address space, and most importantly kernels can't change their offset throughout their entire life cycle! This means a single memory layout leak will defeat KASLR until the machine is rebooted. It turns out that this kind of bug is said to happen pretty often by Spender.
This is exactly why Linux KASLR is weak, and even "a failure" according to Spender. The mechanism was not intended for kernels. Do read his article if you want more details. He does speak about other implementations and you should understand from the points made above that it is not the implementations only that are weak, but rather the design. KASLR needs a lot more care in how it is implemented than traditional ASLR because the conditions for exploitation are much more favourable.
Edit: and apparently you're just a Google search away from knowing how to exploit the Windows KASLR implementation.


How to use one time pad if the key is shorter than the plaintext?

"One-Time Pad" is more a concept than a strictly-defined algorithm. If there was a specification of an "OTP encryption algorithm" (say, in RFC format or similar), which tells where each byte goes and when, then that specification would tell you what happens when the key length does not match the data length. Moreover, if, in the case where the key is shorter than the data to encrypt, that specification told you anything else than: "if the key is shorter then encryption must be aborted"; then that specification would not qualify as a true implementation of the "One-Time Pad" concept.

In that sense, there cannot be any "key wrapping around" for a One-Time Pad because then the "pad" (i.e. the key) is no longer "one-time".

An OTP algorithm specification would be quite simple, but there is still room for variants. When the data to encrypt is a sequence of bits (as is typical in computers), then it is customary to talk of the OTP with XOR as operation for encryption and decryption. However, any group operation can do the job. For instance, if the data is a sequence of octets (aka "bytes"), as is also very typical in computers, then you can do an OTP with a byte-by-byte integer addition (modulo 256), while decryption would use subtraction. This also works well and fulfils the One-Time Pad concept. Many pre-computer uses of OTP (with papers and human brains) worked with letters, in which the operation was mathematically equivalent to addition modulo 26 (the underlying group being, in that case, Z26, mapped to the A to Z letters).

I am not aware of any established, well-defined specification for a computer-based one-time pad, because, let's face it, for practical usages one-time pad tends to suck. We can find traces of the OTP concept in some degenerate cases (for instance, ElGamal encryption can be mathematically described as a Diffie-Hellman key exchange resulting in a shared key, which is then used to encrypt the short message to send with a custom one-time pad operating in the same group as the DH part).


Keyboards with built in SmartCard reader. PIN/Password to unlock not via Computer

The problem with what you ask for is about sharing the keyboard with the OS. When a keyboard is plugged in a machine, then the operating system on that machine is made aware of every key press and key release event, and the OS maintains the knowledge of which key is pressed at any time. For your PIN entry scenario, you not only need the key presses to be sent to the smart card, but you also want the same key presses not to be sent to the operating system.

The keyboard, by itself, won't be able to guess whether you are about to type a PIN code. You could imagine a specific command sent from the computer, which tells to the keyboard: "now, key presses should be sent to the smart card, not to me". But you do not trust the host computer (that's the point of the discussion), so you cannot trust it for actually sending this command. Therefore, your special keyboard, if it exists at all, should have a manual switch or at least an indicator LED which the OS cannot override (e.g. the LED turns green when key presses are sent to the smart card).

You would not be at the end of your worries, though. Because when you use the smart card to perform a payment, the card "authenticates" the payment order (with some operation that the bank will accept as valid; this could be a MAC
or a digital signature). You then want to be sure that what the card sees and signs is indeed the payment order you believe. Since you do not trust the host computer, you need an extra display.

When you go down the road of "host computer is potentially hostile", you normally end up with the idea that the smart card reader should have its own keyboard and display, so that it may show you what you are about to sign, and makes sure that your PIN code goes to the card only. Ideally, the reader should run the banking application itself (to assemble the order in the right format). At that point, you have a payment terminal, which is a small, tamper-resistant computer with its own CPU, RAM, Flash, display, keyboard and smart card reader. The important point is that, short of a full-featured payment terminal, you will not get substantial security against an hostile host computer.

The easier way is to trust the host computer, so that you may reuse the components that the host computer already offers: CPU, RAM, storage, display, keyboard...


Does Reinstalling windows ensures removal of all malwares/spywares/virus/rootkits etc?

If your laptop has only one hard-drive and you format it, you should be fine. It doesn't prevent you from getting infected by the same vector again though.


Is mattermost encryption for group messaging and file transfer secure?

After reading the security details it seems very secure for me. Just to remark some details:

Using AES-256 Algorithm: AES (Advanced Encryption Standard) is the Standard and most widely used private key algorithm.
RSA with 2048 bit is the most widely used public key algorithm in data transmissions.
TLS: is a high security transmission protocol used widely too.

Logging, History, Updates... also makes mattermost so secure.


How eavesdropping attack takes place in network

The possibilities of how this can happen are manifold.  An attacker will need control of a single computer within or just outside the network.  Depending on the network, it might be possible to sniff significant parts of the traffic.  It is difficult to detect passive network sniffers.  An IDS might detect tries to exfiltrate the sniffed data, but the details of what's detected or not are highly specific to the IDS that's used.

Furthermore, if the attacker manages to place themselves in an privileged position just outside of the systems protected by the IDS, it will basically be undetectable.

To give you a better grasp of how this might work, here is a not-so-contrieved example of passive eavesdropping: Imagine a data center where anybody can by rent a place for their server.  Now assume that the network hasn't been setup properly, leading to traffic being randomly sent to the wrong machines (yes, that happens).  Those packets could be sniffed by other servers in the data center; no IDS would detect this kind of eavesdropping as it is done outside of the responsibility of the IDS.  The attacker would not be able to see all traffic to and from their target, but sensitive data could be sniffed regardless.


Does limiting a web session to one browser window or tab provide added security?

Limiting the session to apply to only one tab can be a useful protection, even though it comes with a usability downside that probably makes it not worth it in most cases.
Some attacks (e.g. reflected XSS, CSRF or clickjacking) rely on the attacker tricking the victim into clicking a link. The risk of the victim clicking such a malicious link is decreased if it has to be done in the tab with the open session. In the same way that logging out when you are done protects you over time, keeping the session to one  tab protects you over "space".
So limiting the session to one tab can sort of make sense. What I don't get is why you would be logged out in both tabs when you open a second tab, insead of not just being logged out in the second tab. Maybe they wanted to get the security benefits I describe above and couldn't figure out a better way to do it? Or maybe you are right, and they are just using security arguments to cover up bad design.


Describe an example of indistinguishability obfuscation or functional encryption

The article actually describes two constructions, the second one using the first one as a building tool. The first construction provides indistinguishability obfuscation while the second one is functional encryption.

Indistinguishability obfuscation is a rather esoteric property, which is not what non-academic think about when they hear "obfuscation"; the terminology is a misnomer. That property means that if you can encode some "processing" as a circuit (roughly speaking a piece of code which can be unrolled, with no infinite loop), such that there are several possible distinct circuits which yield the same results, then indistinguishability obfuscation allows publication of an "obfuscated circuit" such that anybody can run the circuit and obtain the result, but outsider cannot know which of the possible circuits was used as a basis internally.

What good IO can make, by itself, is unclear. The authors, in section 1.7 of their article, still present an example, which is rather far-fetched:

  Software developers will often want to release a demo or restricted use version of their software that
  limits the features that are available in a full version. In some cases a commercial software developer will do
  this to demonstrate their product; in other cases the developer will want to make multiple tiers of a product
  with different price points. In other domains, the software might be given to a partner that is only partially
  trusted and the developer only wants to release the features needed for the task.

  Ideally, a developer could create a downgraded version of software simply by starting with the full version
  and then turning off certain features at the interface level -- requiring minimal additional effort. However,
  if this is all that is done, it could be easy for an attacker to bypass these controls and gain access to the
  full version or the code behind it. The other alternative is for a software development team to carefully
  excise all unused functionality from the core of the software. Removing functionality can become a very time
  consuming task that could itself lead to the introduction of software bugs. In addition, in many applications
  it might be unclear what can and cannot remain for a restricted use version.

  One immediate solution is for a developer to restrict the use at the interface level and then release
  an obfuscated version of the program. For this application indistinguishability obfuscation suffices, since by
  definition a version restricted in the interface is indistinguishable from an obfuscated program with equivalent
  behavior that has its smarts removed at the start.

The use case is dubious, at best. However, IO has a more useful (theoretical) functionality, which the authors expose afterwards: it enables them to build functional encryption.

Functional encryption is about providing a computable circuit (obfuscated with IO) which receives as input encrypted versions of some value x, and returns F(x) for some function F, without revealing anything else about x. The authors show how they can do that for any function F which can be encoded as a circuit, and the resulting obfuscated circuit is "polynomially-sized" with regards to the original unobfuscated circuit implementing F.

Now this "polynomially-sized" expression tells us that we are in the abstract world of mathematics, and not in the practical world. It relates to asymptotic behaviour when circuit size grows towards infinity. It does not tell much about how much the construction would cost in any practical, finite situation; only that if God plays with Universe-sized computers, then He will find the construction to be "tolerably efficient" provided that He first creates a large enough Universe to accommodate the bulk of the involved computers -- with no a priori measure of how large that Universe has to be for the theoretical result to apply. Empirically, we find that most mundane algorithms that we manipulate and that offer polynomial complexity are "somewhat fast", but that's mostly because these algorithms are very simple things; there is no proof or even suggestion that the construction described in the article would be as "mundane".

Functional encryption, if it can be made to work within reasonable CPU and RAM budgets, can be useful for security in a number of situations. For instance, imagine a FPS game opposing players on networked computers. For efficient 3D rendering, the local machine of each player must know the terrain map and the current location of all objects, including other players, so that it may decide whether, from the point of view of the local player, any other player is visible (and must be drawn on the screen) or hidden (e.g. sneakily poised behind a wall, ready to lob a hand grenade) -- but cheaters would find it very convenient to know these locations in real-time. Each player is assumed to have complete control of his machine (he has physical access). With function encryption, the player's machine may compute the rendering (that's the F function) based on the locations as sent by the server, without obtaining the locations themselves.

Unfortunately, for practical applications, we are far from having a workable solution. What must be understood is that in all these constructions, each circuit gate must map to an instance of Gentry's fully homomorphic encryption scheme, and at every clock cycle for the obfuscated circuit, all gates must be processed, regardless of whether they are "active" or not in the circuit (this is a big part of why the obfuscation theoretically works: it does not reveal active gates, by always making them all active). This article gives performance result: on a rather big PC, we are up for minutes of computation. That's for each gate in the obfuscated circuit, and for each clock cycle.

There are millions or even probably billions of gates in the envisioned circuit, given the setup of functional encryption: the "obfuscated circuit" must include asymmetric decryption and validation of zero-knowledge proofs. So now we are talking about using all the computers currently running on Earth, all collaborating on the computation, and they might make non-negligible progress towards running one instance of functional encryption within a few centuries.

These are just estimates that I make from what I saw in the articles, but they should give you the order of magnitude. Namely, that the albatross metaphor falls very short of the reality; you'd rather have to imagine a full army of spaceships bent on galactic domination. If it flies at all, despite bureaucratic heaviness, it will have tremendous inertia and be quite expensive.


Storage of secret key in resource-constrained sensor nodes

Generally the "master key" is different from derived device keys. You do not store the master key in the devices. Where to store the device key is dependent, but generally you'd store it in flash / EEPROM (or whatever persistent but writeable storage there is).

If possible the storage is protected and / or encrypted. This is perfectly possible, it's commonly used with smart cards. However, it does come at a cost and it depends on the nodes if such cost is economic. When it comes to implants, I guess you don't expect an adversary to remove it from the body first, so I presume some attacks are not applicable.


How difficult is it to crack salt portion of hash

If your "random string" is really a "random string", then none of your tricks can do any good. For that matter, the salt won't make things better either. Neither the use of bcrypt (what PHP calls "crypt with Blowfish").

Indeed, all the games with salts and iterations are just ways to cope with the inherent weakness of passwords. Passwords are weak. They cannot help being weak: they fit in a human mind. So as long as human users are, say, human, we must deal with passwords, and since passwords can be (for most human users) brute-forced, we must apply "tricks" which make the attack harder. The two main tricks being slowness (making the hash function inherently expensive through many iterations) and salts (to prevent parallel attacks and precomputations). I have written extensively on the subject there.

However, if you have random strings between a computer and another computer (smartphones are computer), then no human, then no problem. A sufficiently long and sufficiently random strings defeats brute force by its sheer randomness. Salts and slowness do not bring any additional security: it cannot be brute force, period.

(Or, said otherwise, if your random string can be brute forced, then you are doing it very wrong.)

It all boils down to this sentence of yours:

  Later on, I decided that sending the same SID everytime is not secure enough

Why ?

Simply, why ? Why would it not be "secure enough" ?

There may be good, rational reasons. But you cannot make anything of value, in the domain of security, if you don't take the time to think your requirements through. Define your security: your goals, the attacker's goals, the attacker's powers, the assets at stake...

Anyway, if the communications between the application and your server need any kind of confidentiality or integrity or authenticity (I suppose this is the case, since you bother with authentication), then there is no escaping it: use SSL (also known as "HTTPS"). No SSL, no real security. But with SSL, things are fine. You can send your "random string" (which really is a custom session cookie) as is, it won't be intercepted by third parties, active or passive.


The simplest solution is to use mutually authenticated TLS. This will only authenticate the communicating parties.


Sign a User certificate with CA.key :openssl

You included -x509 on your original request, which in this case instructed openssl to generate a self-signed certificate named certname.pem.  It is a certificate, but probably not the kind you want here.

I assume you instead want to use your newly minted CA to sign your public key and create a server certificate.  You'll need to first generate a Certificate Signing Request (CSR); since you have already generated the key (the one in keyname.pem) you can do this with:

openssl req -out keyname.csr -key keyname.pem -new

You can then pass this CSR to generate a certificate (as you tried):

openssl ca -create_serial -config openssl.cnf -cert ca.root.pem -keyfile ca.key.pem -in keyname.csr -out new-certname.pem


What is the function call for escaping `php` in php

I'm fairly certain that there is no php standard library function that does that. So it's probably some kind of home brew. Off course, it's impossible to say exactly what the function looks like without access to the source code or extensive testing, but one simple guess would be something like this:

$halfway = str_replace('<', '<-- ', $input);
$result = str_replace('>', '-->', $halfway);

But there is an unlimited number of possibilities here. Your best bet is to play around with it and see if something unexpected happends.

Another tip for bypassing this... I found this little note in the changelog for PHP 7.0.0 in the PHP manual:

  The ASP tags <%, %>, <%=, and the script tag <script language="php"> are removed from PHP.

So if you are running PHP below 7 you could try those. Or just a simple <?=.


Creating secure circuit in first generation Onion Routing

In the theory of onion routing, the underlying routing graph is complete. All routing nodes can talk to the initiator's proxy and the receiver's proxy. In TCP/IP terminology, the initiator's proxy, receiver's proxy, and the routing nodes, all have fixed public IP addresses, and any of these machines can open a TCP connection to any other of these machines.

In that sense, the route is not so much discovered than defined. All routes are possible; the initiator just selects one.

The conceptual difficulty here is in realizing that there are two very distinct layers. Physically, there are not wires going between any two pairs of machines; any communication from machine A to machine B will need to go through a number of intermediary hosts. However, once that system is up and running (that's the "Internet"), we can reason about it as an abstract method that can convey information between any two systems. It is the encryption that allows for this abstraction: routers that are physically involved in transferring data from node A to node B won't be able to know where the data should go after node B because that information is encrypted and only B has the decrypting key.


Why does some malware limit their scope to certain countries?

Not sure if @Fis is joking, but he's not far off.

One thing we know about Russia for example is that the government doesn't care at all if a Russian hacker defrauds US citizens or institutions, but if that hacker (accidentally or not) targets a Russian bank, the fury of the State will come down upon him hard. Israel has similar "do it over there, but don't do it here" laws.
Damage control. If you write malware to steal USD from US banks and it spreads like wildfire in Africa and Southeast Asia, security researchers will be alerted and your target audience will catch on prematurely. And you'll end up with a bunch of Zimbabwe dollars you can't do anything with. It's safer to perform some sanity checks to see if the malware is in the correct environment before detonating the payload.


PCI-DSS is pretty clear on this point in a few documents:

Here's one for guidance on how to process orders over the phone:

https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf

  the three-digit or four-digit card verification code or value printed
  on the card (CVV2, CVC2, CID, or CAV2) cannot be retained after
  authorization

Period. It does not matter what media is used.


Security of running openpgp.js in a browser with the private key in HTML5 localStorage

HTTPS is still an absolute requirement, and Matasano's main point is that JavaScript can never replace HTTPS.   A MITM attack could deliver a custom JavaScript payload that could read any secrets in localstorage, and an XSS payload could also compromise this data.

Matasano is wrong in regards to random number generators in JavaScript. Most browsers provide a very secure random number generator window.crypto.getRandomValues().  I guess Matasano hasn't read the w3c Cryptography API for JavaScript.  This API contains a random number generator that uses the operating system's entropy pool.


Can i compare linux user permissions without root access?

Run sudo -l as a user to see what supplementary privileges that user may gain by running sudo. You'll have to know or collect the user's password to make use of these privileges, unless one of the sudoers rules is tagged NOPASSWD.

Run id to see what groups the user belongs to. You may then want to look around to see what these groups are worth.

These two are common ways to escalate access and easy to compare. Here are a few more areas you can look at with more work needed to get useful results.

Look around to see what files the user may access. Permissions can be granted via access control lists, not just ownership and group membership. The following commands list files that are respectively readable, writable and executable by the user but not by all users. The first two exclude the user's home directory (where it's unsurprising to have files that others can't access), and the third only targets setuid/setgid executables. These commands run on the root filesystem only, add more paths if there are more mounted filesystems (or remove -xdev and exclude /proc and perhaps /sys instead).

find -xdev / -path ~ -prune -o -readable ! -perm -a+r
find -xdev / -path ~ -prune -o -writable
find -xdev / -perm /u+s,g+s -executable ! -perm -a+x

Check the user's log and configuration files to see what kind of administration-related things they've been doing: shell commands in ~/.bash_history (or other files depending on the user's choice of shell and configuration), aliases in ~/.bashrc (likewise, or other files), scripts in ~/bin, …

Check if the user has SSH keys (in ~/.ssh/) that you may use to escalate your access to other machines (or occasionally to other accounts on the same machine). You may be able to see what sites the user has logged into by checking ~/.ssh/known_hosts, but by default the addresses are hashed so you can only verify guesses.

If this is a desktop machine, check for a running password manager. You're unlikely to find one on a server, but there instead check for an existing SSH connection that you may be able to piggyback onto (e.g. via X11 forwarding).

Emails may also give a clue. Check who administrative emails are forwarded to (/etc/aliases) and who has a local mailbox in /var/mail or /var/spool/mail.


Force a subordinate CA cert to be signed to include a the CRL distribution point extension?

I've reviewed the contents of /etc/pki/tls/openssl.cnf, and the following should work to produce a usable -extfile for use with the previously mentioned command (openssl ca -extensions v3_ca -extfile /root/ca/opensslx509.conf -days 730 -out /root/ca/certs/public.cer -in /root/public.csr).

echo "[ v3_ca ]" > /root/ca/opensslx509.conf
echo "subjectKeyIdentifier=hash >> /root/ca/opensslx509.conf
echo "authorityKeyIdentifier=keyid:always,issuer >> /root/ca/opensslx509.conf
echo "basicConstraints = CA:true >> /root/ca/opensslx509.conf
echo "crlDistributionPoints=URI:http://CRLSERVER/CRL.pem" >> /root/ca/opensslx509.conf

I have not tested this at this point.


How to prove a user is actually the perpetrator of certain actions?

Not sure I totally see the problem. Are you concerned that a user could claim you used their private key because you have access to all users keys?

Private keys should ideally be stored one for each user and not in the system itself. I don't know the ins and outs of your system, but could you not get each operation to require the user to attach their private key to complete the operation (this could even by handled client side in some sitations so you can maintain a true 'Trust No One' approach)

If you are concerned users will claim they never owned the private key can't you make a step in the operations to require proof of private key. Such as requiring the users to decrypt something your system encrypts using the public keys?


Is XSS possible if I insert untrusted data into an quoted HTML attribute and HTML encode the " sign?

Yes, if the attribute is double quoted and you are encoding the double quote character, then it shouldn't be possible to escape from the quoted attribute.

However, I would also encode the & symbol because that can be used to start an encoded character in itself.

The HTML5 spec states:

  A double-quoted attribute value is specified by providing the
  following parts in exactly the following order:

  an attribute name
  zero or more space characters
  a single "=" character
  zero or more space characters
  a single """ character
  an attribute
  value
  a """ character

  In addition to the general requirements for
  attribute values, a double-quoted attribute value has the following
  restriction:

  must not contain any literal """ characters


From a security perspective the answer is to never send anything you don't want the user to know to any system the user controls.

From a UX perspective, having a bunch of extra data that's only visible if they open developer tools shouldn't be a problem. Anything they see in developer tools isn't "user experience", it's developer experience. Having stuff encrypted or encoded just makes the "developer experience" worse.

From a performance perspective, having multiple, or many, or uncachable, GET requests usually isn't a huge problem. The details depend a lot of your tech stack and your end-users' situations, but typically you can mitigate related performance problems by

Looking at your caching situation. Don't go overboard, but, counting the user's browser-cache, caching at two or three levels of the tech stack may be appropriate. Particularly, your server could cache a broad DB query, and then perform filtering before sending the data to the client.
Tune your server. This is a massive rabbit-hole; the specific thing I'm suggesting is that you make sure HTTPS connections are being kept open for a little while. 30 seconds or so is often good. That will speed up HTTPS requests that happen while the connection is still alive.
Batch requests. Either let the client request large lists of specific resources in a single request, or move (even duplicate) the logic that would determine what followup resources are going to be needed from the client to the server. You could also look into using HTTP/2 Server Push.
As a last resort, just buy a more powerful system. It won't make an unworkable solution workable, and it'll feel like a cop-out. But it can make a sluggish system feel performant, and it will handle larger traffic spikes without hanging.


a pcap would be useful PROVIDED whatever process is responsible for generating the packets isn't also protected by any sort of application that is intercepting system calls.  I.e. most good viruses typically use a loader that prevents the OS from reporting packets or processes generated by specific processes.


The DMZ should generally be the only network publicly accessible; versus the private network ("Production net"?), where no ports should be 'directly' publicly accessible. Connections between the two segments are largely dependent upon your application's requirements.

The key is that the private segment is not directly accessibly, so one (or more) devices would need to be compromised to get to them.

If the private network (non-dmz) needs to connect to a DMZ server, that is assumed to be more trustworthy than an Internet host connecting (you're more trusted server is connecting, versus anyone in the world).


Why is secp521r1 no longer supported in Chrome, others?

The main culprit is NSA Suite B -- or, rather, people who read that document as something that it is not. NSA Suite B says that NSA uses curves P-256 and P-384. Some people have chosen to interpret that as "don't use any other curve". P-521 (aka "secp521r1") is not one of these curves, hence its removal.

There is nothing wrong with P-521, except that it is, in practice, useless. Arguably, P-384 is also useless, because the more efficient P-256 curve already provides security that cannot be broken through accumulation of computing power (see this answer for a discussion on that subject). Yet people and even NSA uses P-384, which goes a long way to show that the choice of what elliptic curve to use in a given cryptographic protocol is not fully a matter of pure rational logic and security assessment. People who are in the position to decide whether a given curve is acceptable or not will make choices based on their perception of how their choices will be perceived by other people who themselves are not necessarily the most logical of thinkers (or not at least perceived to be such).


password brute force over ssh? (not on ssh)

Hydra does not support that mode.
The closest it comes is the Cisco Enable mode, where a telnet connection is used to log into the device and then the enable command is repeated to try different potential enable passwords.  It might be possible to write a new module by cribbing code from hydra-cisco-enable.c and hydra-ssh.c to do what you want.
Alternately, if you have expect, you can use that to write a password guessing script.


How should this system be protected from ARP spoofing?

There is a possibility to encrypt the connection to the proxy, there was a question on this site.Please find the link mentioned below.However the methods mentioned may not work at all times.

Is it possible to connect to a proxy with an ssl (or otherwise encrypted) connection?

To answer your query regarding implementing this on the network infrastructure:

There is a feature called Dynamic Arp Inspection.This can be enabled on supported switches.Each ARP packet is looked into by the switch and the IP mac binding is verified with a Trusted binding table.(I believe that the binding table is populated by snooping into DHCP at the time of IP allocation and i guess static binding between IP and mac can also be configured on the table).So any ARP packet with an incorrect mapping between IP and ARP is dropped hence preventing poisoning.