If the guest is compromised, can it permanently infect the GPU and its
  firmware?

According to OpenStack documentation, yes.

  Many hypervisors offer a functionality known as PCI passthrough. This
  allows an instance to have direct access to a piece of hardware on the
  node. For example, this could be used to allow instances to access
  video cards or GPUs offering the compute unified device architecture
  (CUDA) for high performance computation.

  This feature carries two types of security risks: direct memory access
  and hardware infection.

Direct memory access is only relevant to device passthrough not using IOMMU.

  Even though VT-d/IOMMU is designed to securely contain devices to the
  virtual machine, could the guest use the GPU to compromise the host
  (OS or any other devices)?

Possibly, if the device is used by the host.

  A hardware infection occurs when an instance makes a malicious
  modification to the firmware or some other part of a device. As this
  device is used by other instances or the host OS, the malicious code
  can spread into those systems. The end result is that one instance can
  run code outside of its security domain. This is a significant breach
  as it is harder to reset the state of physical hardware than virtual
  hardware, and can lead to additional exposure such as access to the
  management network.


is it secure to use proxychains+tor while logged in as root

Running those programs themselves would be pretty safe if they really need to run as root (I'm sure they can be ran as a normal user with the correct configuration).

What is definitely not secure is being logged in as root and running everything else as root, like a desktop environment or a web browser.


How to decrypt sensitive information with a token and a password

I think this question is actually three questions.

Username/password authenticates the user to the application.  This establishes a user identity. If you then issue them an API token, this authorizes them to use particular API functionality.  Encryption should be completely decoupled from these other actions and handled entirely server-side.  An example flow:

User A logs in to example.com. As part of the authentication flow, they are issued a signed bearer token that contains their user identifier and their permission set (standard user).  This user wants to view a private document in their account. Their browser makes an API request and passes the bearer token (plus a CSRF token, etc) with the request.  The API then validates the permission set on the token and the user identifier's access to the resource.  If the authorization check succeeds, the server retrieves the appropriate encryption key (from a secure store) for the resource, decrypts it, and returns it to the user.


Is it a security vulnerability to tell a user what input characters are valid/invalid?

... that could be useful in an attack but is normally not available to the attacker

Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users away since they cannot continue.


I can't think of a way to search for your first request. I am not aware of methods of finding software by its compiler.
As to your second question, these are the resources I've found:

The legislative situation in Canada in 2006 - A summary of legislation that was in place back in 2006.

Solicitor General’s Enforcement Standards for Lawful Interception of
Telecommunications from 2008 - A standard describing what the Canadian authorities require from telecommunications solutions.

An article from 2015 that discusses the state of encryption in Canada.

And in this book, chapter IX, page 266 - where he discusses the topic in depth.


Why not use a CA and limit authorization by certificate? Then you can harden your server and let the CA handle whether or not a given certificate is valid. You can then use the "management" certificate to sign the "minion" certificates. Then you have strong two-factor authentication if you add a username and password as well.

To limit access to the server, you should require a key to gain access, and store the key on a USB stick (or two) and store them in a dual control location. You could also use this method to store the super-secret private key if you go with your scheme.


How to detect the "Hello packets" sent by a wifi enabled smartphone

I believe spartan is talking about Wifi "probe requests".  You can capture these using wireshark when your wireless adapter is set to "monitor mode".

You can filter for them using the following syntax:

wlan.fc.type_subtype == 0x04

These are managment frames and are basically frames sent from your client to find out which wireless networks / AP are around.

More information can be found on Hak5's episode on probe requests.

If you are talking about these other "hello packets", such as automatic pings or so, then Wireshark is still your friend.


Strange logs in apache from bing/facebook

As stated at the page linked in the user-agent string, the page is "crawled" because someone tried to share it on Facebook.

  Facebook allows its users to send links to interesting web content to
  other Facebook users. Part of how this works on the Facebook system
  involves the temporary display of certain images or details related to
  the web content, such as the title of the webpage or the embed tag of
  a video. Our system retrieves this information only after a user
  provides us with a link. You may have found this page because a
  Facebook user sent a link from your website to other Facebook users.
  If you have any questions or concerns about any links or content sent
  by one of our users, please contact us at legal@facebook.com.

Maybe someone made a typo in an URL while trying to post something on their wall?
Alternately, it is possible that those URLs were valid before you bought the domain (it may have been previously owned by someone else).


How can clicking a link in a Facebook users news feed compromise their account

Though I'm not much of a Web security person, there are at least three ways for your account to be "compromised":

You installed a malicious browser extension: as long as you have a cookie allowing you to autoconnect on Facebook, it may be able to go there and use your account as it pleases (that depends on what the extension API of your browser allows, I'm not up to date with that). It could also spy on you when you login and steal your password. Solution: don't install dubious browser extensions!
You installed a Facebook app: if it asked for the permission to post on your behalf, look no further. Usually those apps also ask for some information about your contacts and/or your account so they have a means to spread and some data to sell. As a rule of thumb the vast majority of Facebook/Android/iOS free apps are here to steal and monetize your data.
You visited a page asking you to connect with your Facebook id: usually to "verify your age". These get you to connect on their page and then make your browser run a JavaScript routine that'll post on your behalf. How exactly? I'm not sure, that depends on what the JS engine of the browser allows (e.g., can you influence the contents of an iframe from the outside? can you simulate clicks or text input in that frame?).

Hopefully someone can develop a more precise answer.


Securely launch local application from IE?

It's just an idea - haven't tried it: Could you create a symbolic link to the actual .lic file in a different folder?
To do so, go to a command line window, and type:
mklink /H Link Target

With Link being the full path to the file where your application 'thinks' that it is, and Target being the full path to the actual file (outside of your 'Program Files' directory).
Here's a great guide if you like to read up more about symbolic links


How to get CSRF token on authorization request with OWASP ZAP in bruteforce mode

Theres actually an easier option when using the fuzzer.
Add the 'Anti-CSRF Token Refresher' Message Processor - that will automatically regenerate the token for you :) If its not available then you should just need to tell ZAP about the token name.

Its worth noting that currently we only support CSRF tokens in the body, not in the URL.

Oh, and FYI in the next version of the fuzzer addon this Message Processor will be added by default if we detect a CSRF token in the message being fuzzed :)


Performing a vulnerability assessment on Windows Tablets?

For the main part, configuration assessments of windows tablets are exactly the same as for standard windows builds and the approaches and resources would be the same (e.g. CIS security benchmarks).  The only likely unique point for a tablet review would be the presence/absence of hardware features like TPM chips which can support full disk encryption.

Windows RT as run on the surface is a slightly different case as it is a more locked down version of windows, but it still has a command line and powershell, so it would be possible to assess the configuratio of the device in largely the same way as you would assess a standard windows build.

There are some potential differences in terms of manageability (e.g. Windows RT cannot be domain joined) but whether those are relevant depends on the specific organisation requirements, so the best approach here would be to lay out specific requirements and then manually assess against each one.

From a black-box review perspective (e.g. using tools like Nmap and Nessus) the approach would be the same as for any system.


Is this input field and function secure?

"if someone turns js off, can the input field be used for any kind of XSS attack"?
no, you need JS to pull off XSS, but a server is still needed to stop other attacks like SQLI, malware links/downloads, and CSS phishing.
$(elm).html(str) is more dangerous than elm.innerHTML=str because it loads external scripts and eval()s any content in inline script tags, whereas innerHTML doesn't execute script tags. Both are susceptible to attribute-based attacks like onmouseover=alert(666) however, so sanitize all user-submitted content on a server before serving to other users.

EDIT: I should mention that you can safely use elm.innerText=str on arbitrary input, and it preserves some human-desired formatting and special chars, without any XSS risk. $(elm).text(str) does about the same thing, so it's also safe.


Why does chrome connects to MarkMonitor (always on startup)

I think the confusion here lies in that 1e100.net appears to be owned by MarkMonitor. Actually, MarkMonitor have registered (and "protect") this domain for Google.

You can see here that Google own 1e100.net: What is 1e100.net?

So Google Chrome is phoning home but to Google's servers.


Are security questions considered as 2FA?

There are main 3 factors

Something You know - Password, Question, PIN..etc (Type 1)
Something you have - Token, Smart card...etc  (Type 2)
Something you are  - Iris scan, Fingerprint...etc (Type 3)

If you want to multifactor you can use combination of them. Security question and password are in same category. That mean it is not a two factor.
In addition that

Somewhere you are
Somewhere you are not

also consider as deferent factors. You can use combination of these factors as well. Then it will become multi-factor.


Will OpenSSL's TLS-SRP still provide PFS if all credentials are public?

This is not a good idea. But that's not a problem of SRP.

SRP is a Password-Authenticated Key Exchange protocol by which two parties establish a shared secret with mutual authentication through another shared secret. The beauty of the thing is that the initial shared secret may be weak (i.e. a password that human users can remember), and yet the new shared secret is not susceptible to offline dictionary attacks.

A dictionary attack is a brute force attack on a human-compatible secret. The attacker tries "potential passwords" until the right one is found. An offline dictionary attack is a dictionary attack where the attacker has obtained enough information to test passwords at home, without interacting any further with the target systems; e.g., if the attacker has a hash of the password, then he can try passwords by hashing them and comparing with the known hash value. Offline dictionary attacks are powerful because nothing prevents the attacker from throwing more power at the task, through dedicated hardware (GPU, FPGA, ASIC...), rented systems (commercial clouds), or even "borrowed power" (idle machines in a University network, botnets...).

A contrario, if an offline dictionary attack is not possible, then the attacker must use an online dictionary attack, and then things begin to look better because the honest systems can limit the rate at which they respond, or even stop responding after too many failure. This is the behaviour of a smart card with a PIN: after a few wrong PIN, it just locks itself.

The whole point of PAKE is to avoid offline dictionary attacks. Attackers MUST talk with either the genuine client or the genuine server whenever they want to test a potential password. This has a few consequences for your case:

PAKE protocols, in particular SRP, naturally provide forward secrecy (also known as PFS). Forward secrecy is about preserving confidentiality of past communications even against attackers who later on manage to steal long-term stored secret values of either or both parties. In the case of TLS-SRP, the only long-term stored secret value is the shared password.

Suppose that there is a procedure P by which an attacker, after having recorded (passively) a connection, and having later on stolen the shared secret (the password x), can unravel the contents of the connection. Forward secrecy is achieved if such a procedure P does not exist. However, if P exists, then the attacker can turn it into an offline dictionary attack: the attacker just has to "guess" the password x, and try procedure P using that guessed value of x. If it works, then the guessed password x was correct.

In other words, if a PAKE protocol does not provide forward secrecy, then, mechanically, it does not provide protection against offline dictionary attacks either, so it is not a "true" PAKE protocol. Conversely, good PAKE protocols like SRP necessarily provide forward secrecy.
The explanation above naturally extends to the case of a public password. A public password is just a password for which dictionary attacks are really efficient (attackers get it right on first try...). Thus, you still get forward secrecy even if the password is known to everybody.
However, all of this relies on important details. The "forward secrecy" property is about an attacker who passively recorded a connection, and tries to decrypt it afterwards. In particular, it says nothing about active attackers.

If the password is known to everybody, then the attacker may pose as a fake server, or a fake client, or both at the same time; notably, the attacker may run a Man-in-the-Middle attack. Such an active attacker can then intercept connections and see all the data as it flows. Since the MitM still forwards data both ways, the genuine clients and servers will be none the wiser.

This explains why I used emphasis on the "mutual" word at the start of this answer. When you say:

  we explicitly do not want authentication, we just need the encrypted data for each session to be protected

then this is a kind of contradiction in terms. What you really mean is either of the following:

you do not want client authentication (but the client must still have some guarantee that it talks to the right server);
your usage context is such that attackers cannot be active.

Passive-only attacker contexts are, in fact, extremely rare, and most people who just assume that attackers can not alter data in transit are merely delusional, and primed for a rude awakening at some point. So we are back to point 1: the client should still be able to know whether it talks to the right server. In SRP, the shared password is the basis for mutual authentication. By making it public, you remove authentication in both directions, and that's too much removal.

There cannot be any notion of authentication if everything is known to everybody. But SRP is based on the idea that the only secret is the shared password. So you cannot get server authentication if that only secret is not, in fact, secret.

If you want an "unauthenticated" communication (server does not know who the client is; but the client still knows who the server is), then SRP is not the way to go. Rather, you will have to use the "normal" SSL/TLS in which the server has a public/private key pair, and the client knows the public key, or learns it dynamically through the server's certificate (the latter implies certificate validation, which is what Web browsers do, but maybe you would have preferred to avoid certificates altogether).

Summary: yes, SRP provides forward secrecy, even if the password is public. But no, this is not a good idea, because forward secrecy is not the only thing you really want; you also need normal secrecy, and that one cannot be maintained against active attackers if you use SRP with a public password.


Blocking reflected XSS on common web servers

These headers never blocked XSS at the web servers but instead instructed the browsers to use heuristics to detect XSS on the client side.
There is no magic way to block reflected XSS on the server side. And there is no "Without any code change / WAF", at least if you are having a broken application affected by reflected XSS in the first place.
One can use heuristics to filter for common XSS attacks, i.e. use a WAF. Better yet, the code should have proper input validation and output sanitation and should be structured so that a strict Content-Security-Policy (especially no inline eval) can be enforced and will then also be set by the server.


Any security reason to keep PHP short_open_tag off?

There are security reasons for never using short tags in your code.

Your code could easily end up on a server with short tags off, through a migration or perhaps some misconfiguration. If you have been using short tags to mark what is PHP code and what is not, suddenly your PHP will be interpreted as content and served as is. That could leak all sorts of secrets.

But does this mean you should turn the feature off? On the one hand, it's a great way of stopping your developers from using them. On the other hand, if you move in code from somewhere else it exposes you to the problem mentioned above.

There is discussion within the PHP community about deprecating short tags.


Why do digital certificates provide authentication?

You seem to understand that Alice checks that the certificate was issued for the server and that it was signed by an issuer (certificate authority) which is trusted by Alice.

But what you are missing is that Alice also asks the server for a proof that the server actually owns the certificate - a proof which only the server but not Eve can do. This proof is essentially done by Alice giving a challenge to the server and the server signing the challenge with the private key matching the public key inside the certificate.  This signature then can be verified by Alice using the public key inside the certificate.

Since Eve has no access to the servers private key Eve cannot properly sign the challenge and thus Alice will detect that she does not talk to the expected server.


Authenticate user without knowing their password

Do it the way MEGA does it: perform all encryption decryption within your browser using JavaScript. Only allow encrypted files to be sent to the server (unless of course public keys).

You wouldn't need to send the private key at any point to the server (because everything is being done browser side). One small caveat though, if your user looses a password or an encrypted file goes corrupt, then you are basically screwed and all messages will be useless since you don't have the key anymore.

For authenticating the user you could use something like open OpenID. The user would still need to supply a password to decrypt his private key, but at no point is the password decrypted key sent to the server (everything stays within the browser).


Verifying Host Sterility After Running Malware Tests on Virtual Machine

There's no such thing as "verifying sterility"

In general, there's no such thing as verifying sterility, instead you reduce the risk as much as is reasonable and assume the risk that remains. The usually accepted way to ensure sterility of some system is to restore it to a known good state instead of attempting to verify whether the current state is good.

If you do an in-depth analysis of the malware itself and believe that you've understand everything that it does (and how it does it), then you may see that it doesn't contain any VM escape capability, and (assuming you're right!) that it poses no risk for you.

If you follow basic best practices e.g. the VM system is up to date with fixes for any known bugs enabling escape, the network connections of that VM are properly secured, there are no mapped folders where that VM might write data, etc. then it's plausible that you consider that the risk of VM escape is not meaningful for you.

However, if you do consider that the malware might have a reasonable chance of succeeding in VM escape, then you do NOT attempt to verify sterility of the host system - you treat the host system as possibly compromised and follow the standard course of action, which usually is to nuke it from orbit. If VM escape is within your risk profile, then you assume that host workstations may get compromised, don't keep secret data or credentials on them, implement appropriate network security, and treat them as disposable - you would want a capability to easily re-image the host system to a 'known good' setup after each experiment.


Can I generate OpenSSL keys containing provable primes?

I don't think openssl has code to generate RSA keys using the algorithm you want. But you can use any software to generate the values that must be encoded in the private key, and then encode them in the right way so that openssl can then use the key for anything (generate CSR, create self signed certificates, be a TLS server, be a TLs client that uses client certificates, etc.).

The format of the key that you must provide is specified in PKCS#1 [1] and includes: n, e, d, p, q, d mod (p-1), d mod (q-1) and (inverse of q) mod p.

Observe what openssl produces when it generates a private key:

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

This is what's inside:

openssl rsa -in private_key.pem -text -noout

This is how it is encoded:

openssl asn1parse -inform pem -in private_key.pem

 0:d=0  hl=4 l=1212 cons: SEQUENCE
 4:d=1  hl=2 l=   1 prim: INTEGER           :00
 7:d=1  hl=2 l=  13 cons: SEQUENCE
 9:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
20:d=2  hl=2 l=   0 prim: NULL
22:d=1  hl=4 l=1190 prim: OCTET STRING      [HEX DUMP]:308204A20201000282010100CEDECBB4CFA04699F0C849D7FFF9AD1AFAEB422821889A39D3B5D6C216B4D0AF6E60E12221DA77AEFC6C6FB4932764A787AD8A5388382FB34F7592F1BD829A379931AA06D79BA8A23CC2FC0B43E766AB86D5471CD2CB7C90D4953F923C716C82B8F225A26B1D6F23E123301CC5C1D66675567E2FBA2EDA31986416BC9BEAD6A9CA3995AEFB1CE62F21600509489642031EA849325FB0DA6ECEE614642141946493C58B5BE56AEE21A96EB3C0593387067BCE6C11210402A8277CD31E62B0FAF470E51AC1DF87E7AF682562FEF576139F6491E864B190AFCF25E9D18AA89390AF6EC59169AD72851A2428B7C4EEB9E59F2EB4C3E1ADF6A5BE41425922FA06C7A10203010001028201000EFF29C756D1E8AC5A3F3AD334D455CF41E77229549D018935A6D605C5FD9FAF48122FDFF8924CE0DB9DC4CF5367A4AD5C71A138830487B8B906EDFB2660E46B2968E7498DB1D41CC6C8DFDAB5367E43EB07651B5AD0B39C103D2D999D561FA6AE5FA788C9B91D887D56BEB32746F113066899C73DF90D8A50E0D8A11DB07D953A11087FF85B78255CAC52FE55F2F6646EA2521C0CA8F3B2EEFD09B7B3DBEF53A0F7CAB2B0C3AE325F014A1C4FDCB15E2CD3B8AA27A0B0FD1531473CA7CA781B9B675196AE147A17FDBAE6837E50E117D568492EE76EB0C996097A06D892DEB0249574757D8B2FE365DDF1FCC37B755CAD91C76781A7A72ADB9755B179498EFD02818100F2AED36E57E843155C2CD3CACAC84FBFD94DDF13796F2F189109C5A6AC0D345BE1B7EC4CE903618DA045B49D47F24D762566BBEFA2E84E4A5BC10024A9E8964AB60F4B4E7E63948D341BB977E257A17B69AB509123E2A671200BA31E05D39E0F5A5EFF063A11918DEBEC7FD550D0729D5EDBBD466BC0D23D77942200D95901FF02818100DA38E120A3738BB96FC20056186F0A0ED748609E05D50561D7EA2BE439094FF2439F9C03DC6E808F3AB280358D0651632C384C4AA4CE067F319B9426A8B804A3817410F914FF072FCA98024E66067FE572C8ECE5E4FE263BDECC8EDBB60060D0EFF17B1D21FA711E4F8C59D826FAB348595563DCFE41348500F45B310DECF65F0281802A71951CE956FFD48E88708A39290B799C41D850099EFE77A7763411506A06CC430FEDCE0DBABFA70B6EE585D47D763AC193D42EB72935F81F5003FC6592FE2616ED59D862967BF6AE34631DAA827505A69785C1BCAAF93D33C39545BCF323E3BF8479C9D7021798E0B83E2B4AB50A36A7CE7AAE044E76F6B5213D4934BA327502818068BB15A8D16959ECA46B4A3807BFFAE6C6819105262D6748DF141EFE883524EE53701DB368AE8BFAB1A40B8E27E1995BEC5414A15A591A9B1ED6D91278B4E05D0C7B04CE563A535BA772AEE0AB6C812340A497B579E253BD361F9C8C6BDBE09B461CF206385176CAA248ECB1A57B7A61C5A60AA87C4A1507A43EA22977D27B270281806B36867417418016B3E567A514C904E0443C0F8BBABF361230BF8021FC8BE807EB7DA4A77EA72FAB4F12C54C541C97F6368D54D60078A4347942884DBF2240017E1F554A771BD373B949A9B320D1589A617B0E16EC2A61A2C8D6F91F892A436FC553EFD98F371BFD66BB466016E63A3297271EE058025324CB7A5B27A262F099

openssl asn1parse -inform pem -in private_key.pem -strparse 22

   0:d=0  hl=4 l=1186 cons: SEQUENCE
   4:d=1  hl=2 l=   1 prim: INTEGER           :00
   7:d=1  hl=4 l= 257 prim: INTEGER           :CEDECBB4CFA04699F0C849D7FFF9AD1AFAEB422821889A39D3B5D6C216B4D0AF6E60E12221DA77AEFC6C6FB4932764A787AD8A5388382FB34F7592F1BD829A379931AA06D79BA8A23CC2FC0B43E766AB86D5471CD2CB7C90D4953F923C716C82B8F225A26B1D6F23E123301CC5C1D66675567E2FBA2EDA31986416BC9BEAD6A9CA3995AEFB1CE62F21600509489642031EA849325FB0DA6ECEE614642141946493C58B5BE56AEE21A96EB3C0593387067BCE6C11210402A8277CD31E62B0FAF470E51AC1DF87E7AF682562FEF576139F6491E864B190AFCF25E9D18AA89390AF6EC59169AD72851A2428B7C4EEB9E59F2EB4C3E1ADF6A5BE41425922FA06C7A1
 268:d=1  hl=2 l=   3 prim: INTEGER           :010001
 273:d=1  hl=4 l= 256 prim: INTEGER           :0EFF29C756D1E8AC5A3F3AD334D455CF41E77229549D018935A6D605C5FD9FAF48122FDFF8924CE0DB9DC4CF5367A4AD5C71A138830487B8B906EDFB2660E46B2968E7498DB1D41CC6C8DFDAB5367E43EB07651B5AD0B39C103D2D999D561FA6AE5FA788C9B91D887D56BEB32746F113066899C73DF90D8A50E0D8A11DB07D953A11087FF85B78255CAC52FE55F2F6646EA2521C0CA8F3B2EEFD09B7B3DBEF53A0F7CAB2B0C3AE325F014A1C4FDCB15E2CD3B8AA27A0B0FD1531473CA7CA781B9B675196AE147A17FDBAE6837E50E117D568492EE76EB0C996097A06D892DEB0249574757D8B2FE365DDF1FCC37B755CAD91C76781A7A72ADB9755B179498EFD
 533:d=1  hl=3 l= 129 prim: INTEGER           :F2AED36E57E843155C2CD3CACAC84FBFD94DDF13796F2F189109C5A6AC0D345BE1B7EC4CE903618DA045B49D47F24D762566BBEFA2E84E4A5BC10024A9E8964AB60F4B4E7E63948D341BB977E257A17B69AB509123E2A671200BA31E05D39E0F5A5EFF063A11918DEBEC7FD550D0729D5EDBBD466BC0D23D77942200D95901FF
 665:d=1  hl=3 l= 129 prim: INTEGER           :DA38E120A3738BB96FC20056186F0A0ED748609E05D50561D7EA2BE439094FF2439F9C03DC6E808F3AB280358D0651632C384C4AA4CE067F319B9426A8B804A3817410F914FF072FCA98024E66067FE572C8ECE5E4FE263BDECC8EDBB60060D0EFF17B1D21FA711E4F8C59D826FAB348595563DCFE41348500F45B310DECF65F
 797:d=1  hl=3 l= 128 prim: INTEGER           :2A71951CE956FFD48E88708A39290B799C41D850099EFE77A7763411506A06CC430FEDCE0DBABFA70B6EE585D47D763AC193D42EB72935F81F5003FC6592FE2616ED59D862967BF6AE34631DAA827505A69785C1BCAAF93D33C39545BCF323E3BF8479C9D7021798E0B83E2B4AB50A36A7CE7AAE044E76F6B5213D4934BA3275
 928:d=1  hl=3 l= 128 prim: INTEGER           :68BB15A8D16959ECA46B4A3807BFFAE6C6819105262D6748DF141EFE883524EE53701DB368AE8BFAB1A40B8E27E1995BEC5414A15A591A9B1ED6D91278B4E05D0C7B04CE563A535BA772AEE0AB6C812340A497B579E253BD361F9C8C6BDBE09B461CF206385176CAA248ECB1A57B7A61C5A60AA87C4A1507A43EA22977D27B27
1059:d=1  hl=3 l= 128 prim: INTEGER           :6B36867417418016B3E567A514C904E0443C0F8BBABF361230BF8021FC8BE807EB7DA4A77EA72FAB4F12C54C541C97F6368D54D60078A4347942884DBF2240017E1F554A771BD373B949A9B320D1589A617B0E16EC2A61A2C8D6F91F892A436FC553EFD98F371BFD66BB466016E63A3297271EE058025324CB7A5B27A262F099

1 - https://tools.ietf.org/html/rfc3447#appendix-A.1.2


Arp Spoofing Causing Dropped Connections

I have since figured this out.

Arpspoof has changed to version 2.4 since the tutorials i was reading were written.

I removed the IPTABLES entry.

I changed command 3 and 4 to the following:

arpspoof -i wlan0 -t 192.168.0.9 -r 192.168.0.1
arpspoof -i wlan0 -t 192.168.0.1 192.168.0.9

(Note the change in order and addition of the -r flag)


VPN IP address leak while establishing connection

Depending on your vpn software that's normal behaviour.

Configure a firewall that only allows connections to your vpn provider over the public network and force everything else to go over the vpn.

For instance:

iptables -P OUTPUT REJECT
iptables -A OUTPUT -d <VPN_SERVER> -j ACCEPT
iptables -A OUTPUT -s <VPN_ADDRESS> -d <VPN_NET> -j ACCEPT

Where VPN_SERVER is your VPN provider's public address, VPN_ADDRESS is your address on the tunnel interface and  VPN_NET is the VPN network in CIDR notation.

You can also do this with routes instead. When you setup your internet interface, instead of loading a default gateway you load a static route to your vpn server. No host other than your local neighbors and your vpn server will be reachable until you get a default route from the vpn provider (through the vpn).

Both approaches get the job done, but the firewall approach includes an insurance policy for free.


Is Windows 10 backup safe from ransomware?

If the ransomware gains administrator access to your computer then it can damage any backups that the Windows machine may have created on that computer.

If the ransomware only acquires non-administrator access (i.e. you use a non-admin account for web-browsing) then those backups will be safe.

The best thing is to back up to a removable storage device. (surely Windows has an option for this) Keep this device in a safe place, separated from your computer. Not only will your backups be protected from viruses this way, you will still have your backups in the event of physical theft, or hardware failure.

You can also back your files up to a separated server, as long as that sever has been properly configured (and well secured) so that the ransomeware-damaged backups do not overwrite the originals.


Security in unofficial telegram apps(that use Telegram API)

Developers of any application can get hold of the data that passes through the application if they can find a way to transfer the information without you objecting.

This has been demonstrated time and again on all of the mobile platforms app stores with apps transferring data out.

With Telegram, as with any secure comms app, the security is really only in-transit (point-a to point-b). Once data is inside the app, the app can by definition do stuff with it, in general the data cannot remain encrypted within the app.

Cautious or paranoid users will monitor applications for unexpected network activity that might indicate data leaving their machine without permission. This is particularly hard to do on a mobile device due to the app limitations normally applied.


What security issues will I face with outsourced VPS server?

As you have said, any VPS will be accessible by the hosting staff. You should also bear in mind that not all VPS providers will physically host their own servers so there may be a second set of staff who might gain access. This is why it is important to choose a VPS provider you trust and to test out their processes and understand them well.

Of course, your main driver for using a VPS will be cost and the lower the cost the fewer the processes and security certifications they will maintain.

Depending on the type of VPS host, there may be a level of shared resources as well that should be thought about.

In general though, this is rarely a problem unless you are working in a regulated area such as health or finance. In such cases you are unlikely to get away with the use of a VPS and you need to look for alternatives at least for part of your solution. For example, it is typical when taking payments to hand off to a secure payments service for the actual payment (e.g. PayPal or Worldpay).

When using a database with a web front end, you will have to embed the id and password somewhere on the system so a knowledgeable person with access to the hardware will certainly be able to gain access should they wish to.


Sprinkling crypto fairy dust will not prevent the attacker who controls the client from making the client do anything s/he wants with it. S/he can still redirect it to localhost, but now needs to replace the public key you embedded with the app with his/her own public key. Or attach a debugger and disable the use of crypto entirely. Or decompile, remove use of crypto and recompile. You can't control this, because it is all running on the client computer over which your attacker has total control and you have no control, and trying to control it is a losing strategy.

What you need to do is keep the assets that the user wants to access on your server, so it doesn't help him/her to change the client's behavior. If the client connects to localhost instead of your server, they can't access the assets since the assets are on your server, not on localhost. If they try to access services for which they have not yet logged in, your server should reject the request - after all, your server should be tracking who has logged in with a standard session management implementation (don't write your own; it's too hard and writing one's own always results in a vulnerable implementation).

Oh, and you do need to use crypto, but only where it actually helps.  Use TLS 1.1 or 1.2, or use SSHv2 to protect the network traffic. Select strong ciphers. Provide your users with your public key digitally signed by a trusted certificate authority. Encrypt the assets when you store them in your database. Use strong crypto like aes128 or 3des. Generate your key securely, reading the complete documentation about your random number generator, only using one that says it's ok for cryptographic purposes, that is standard, and without taking any chances that you might overwrite the seed instead of supplementing it (some documentation is very misleading, like Java's java.security.SecureRandom).

And finally, either hire a security expert or go learn about security yourself on OWASP.org (a great place to start, but be careful, because they often have mistakes, themselves).


SH Write a file with contents without any special chars

This is quite simple: check for python, perl or any interpreted language availability, then launch the interpreter and just code it !


What stops someone from just redirecting a HTTPS connection to a HTTP version of the site?

The decision on whether to use HTTP or HTTPS is the client's.

If the user goes directly to http://example.com, an attacker could simply hijack that connection and perform a man-in-the-middle attack. If the user goes directly to https://example.com, then the attacker must spoof the SSL/TLS connection somehow; doing so without showing the user an invalid certificate warning requires the attacker to have access to a Certificate Authority's private key. This situation should never happen. Without this, the user's browser would reject the connection, not allowing the attacker to redirect.

In the case of Google and a number of other websites, they set the HTTP Strict Transport Security (HSTS) header, which causes the user's browser to cache a rule saying that they should never ever visit the site via plaintext HTTP, even if the user asks for it or Google itself redirects to a HTTP URL. The browser will automatically re-write the URL to HTTPS, or block the request entirely. This also prevents the user from clicking through a certificate warning in most browsers; the option simply isn't there.


As mti2935 mentions, the Basic Auth header is automatically sent by the browser with every request. That means setting a session cookie is redundant.
However, usage of HTTP Basic Auth should be discouraged, as is discussed in this answer.


Strength of variable-length generated password

Using fewer words from a diceware-style list is equivalent to sometimes allowing passwords with fewer characters. As per the accepted answer to Would allowing shorter passwords sometimes be more secure?:

  The benefit gained by forcing increased length far outweighs the number of possible passwords lost.

The same holds true for shorter diceware-style passwords. So always use the exact length and never something shorter.

EDIT: Note that the problem is not that shorter passwords reduce entropy. They actually increase it. But adding shorter passphrases dramatically reduces the effort to guess the shorter passwords. If your diceware word list has X words and your password will have a length of N, the password has XN possibilities. But a passphrase that is one word shorter has XN-1 or X fewer possibilities. So these passwords will be much more vulnerable than the ones that are just one word longer. The small gain in entropy is not worth the risk to these shorter passwords.

Consider this, if using passphrases that are 1-word shorter improved security, then the argument could be repeated to prove that adding passphrases that are 2-words shorter improved security, and so on. But ever-decreasing length passphrases is clearly a bad idea. So too is shortening a passphrase by 1 word.


At what point does something count as 'security through obscurity'?

The misconception that you're having is that security through obscurity is bad. It's actually not, security only through obscurity is terrible.

Put it this way. You want your system to be complete secure if someone knew the full workings of it, apart from the key secret component that you control. Cryptography is a perfect example of this. If you are relying on them 'not seeing your algorithm' by using something like a ROT13 cipher it's terrible. On the flip side if they can see exactly the algorithm used yet still cannot practically do anything we see the ideal security situation.

The thing to realize is that you never want to count on obscurity but it certainly never hurts. Should I password protect / use keys for my SSH connection? Absolutely. Should I rely on changing the server from 22 to port 2222 to keep my connection safe? Absolutely not. Is it bad to change my SSH server to port 2222 while also using a password? No, if anything this is the best solution. Changing ("Obscuring") the port will simply cut down on a heap of automatic exploit scanners searching normal ports. We gain a security advantage through obscurity which is good, but we are not counting on the obscurity. If they found it they still need to crack the password.

TL;DR - Only counting on obscurity is bad. You want your system to be secure with the attacker knowing it's complete workings apart from specifically controllable secret information (i.e. passwords). Obscurity in itself however isn't bad, and can actually be a good thing.

Edit: To more precisely answer your probability question, yes in a way you could look at it like that, yet do so appreciating the differences. Ports range from 1-65535 and can be quickly checked within 1 minute with a scanner like nmap. "Guessing" a random say 10 digit password of all ascii characters is 1 / 1.8446744e+19 and would take 5.8 million years guessing 100,000 passwords a second.

Edit 2: To address the comment below. Keys can be generated with sufficient entropy to be considered truly random (http://tools.ietf.org/html/rfc4086). If not it's a flaw with the implementation rather than the philosophy. You're correct in saying that everything relies on attackers not knowing information (passwords) and the dictionary definition of obscurity is "The state of being unknown", so you can correctly say that everything is counting on a level of obscurity.

Once more though the worth comes down to the practical security given the information you're able to control remaining unknown. Keys, be it passwords or certificates etc, are (relatively) simple to maintain secret. Algorithms and other easy to check methods are hard to keep secret. "Is it worth while" comes down to determining what is possible to keep unknown, and judging the possibility of compromise based off that unknown information.


The terms of use of the video streaming service most probably explicitly mark the subverting of security measures as illegal.
Probably it's a large site if it has a detection mechanism like this.
If it is legal for you to copy, you could try to find it on a torrent network.


AutoCSR breaks with the principle that the private key should be generated on the machine where it will be used, and never leave that machine. It generates the public/private key pair on a machine of the CA, transfers the private key to you via the Internet in encrypted form together with the certificate, and erases it on the machine where it was created.

On one hand, this does indeed reduce security. Instead of controlling the private key yourself you have to trust the CA's procedures and security measures to ensure that the key generation is done securely, there are really no traces of your secret key left anywhere on their systems, and the key isn't disclosed to or manipulated by a malicious third party in transit.

On the other hand, it can increase security. Generating a public/private key pair securely requires some expertise. There have been incidents of weak keys, as well as services not offering encryption at all because the challenge of setting it up was too big for them, which could have been avoided by using a service like AutoCSR.

In sum, if do you have the experience and equipment available to do it properly, creating the key pair on the target machine will definitely be more secure. If not, it's a trade-off between your organization's capabilities and your trust in the CA to do it right.


Best practices for securing a public facing web server?

I would definitely add that SSH should not allow password authentication alone, but public-key (and/or some second token).

I would personally add enabling seLinux (or appArmor) to the list, and would also enable and configure auditd, and mandating the use of sudo.

There is a lot more you could do if wanted to go above minimal, but I would consider those three things to be part of the base you would want.

If you wanted something a bit more formal, you could look at the CIS benchmarks (https://benchmarks.cisecurity.org/downloads/benchmarks/).
They possibly aren't minimal, but have some recognition (whatever your opinion of the CIS might be).

CentOS (and I suspect RedHat likes) also has some tools for SCAP (https://scap.nist.gov/) you could check out if they apply.


Whether WebAuthN can work as the only factor for authentication or only as a second factor depends, among other things, on the authenticator's capabilities.

The specification's section on taxonomies of authenticators explains this very well: Only authenticators listed as Multi-factor in the Authentication Factor Capability can replace an existing combination of a password and second factor (for example, Password and Yubikey).

Of course, it is ultimately up to the Relying Party, i.e. the site or service allowing WebAuthN-based authentication, to decide whether it is willing to accept a single factor only for authentication (e.g. password only; Yubikey only), a multi-factor capable authenticator (e.g. a CTAP2-capable Yubikey together with PIN entry) or any combination thereof (e.g. password and Yubikey without PIN entry, password and platform authenticator with biometric authentication).

For example, you could imagine a site allowing initial logins using a Yubikey only, but subsequently requiring Yubikey + PIN entry for sensitive operations (e.g. money transfers, registering additional authenticators etc.)


Can oauth2 "state" parameter be used to avoid using session cookies to identify user

I believe You cannot do this securely.

Malicious actor can freely obtain redirects using your application. Now if he manage to make a unsuspecting victim to open redirect address then the victim will see that Your application is asking for access. If he grant access he will be redirected back to you, if you use only state to identify him then you just assigned victim resources to malicious actor account in your app.


Do drive by download attacks include malicious file downloading?

Yes. As you can read on this article, Drive-by download includes:

  downloads which install an unknown or counterfeit executable program,    ActiveX component, or Java applet
  computer virus, spyware, malware, or crimeware

They can rely on the users' behaviour (e.g. malicious simulation of an OS message), or exploit a browser / plugin vulnerability to trigger the file download without user's consent.


What are main differences between Source Code Analysis vs Static Application Security Testing(SAST)?

Often, people use these interchangeably within the security industry.

The lists you are pointing to are referring to the same types of tools/assessment, with the addition that the second list is broader, including static analysis tools that are not targeted at security, such as those used to check for code quality issues.

Some types of SAST technically do not review source, but binaries, so it can be a little bit of a misnomer to call it SCA, in that situation.

I personally like the DAST, SAST, MAST nomenclature, because it delineates between the broad types of assessing applications for security issues: by running tests against a running application (dynamic analysis), by examining the code components or a model of them (static analysis), or by tool-assisted expert inspection and testing (manual analysis).


How common is Perfect Forward Secrecy in HTTPS clients?

All major browsers support ECDHE: IE since IE7 (on Vista and newer), and Chrome and Firefox for even longer.  However, Windows XP users of IE do not get ECDHE support, and even though Windows XP is past end-of-life, people are still using it.  If you want to allow XP users, then I suggest just putting the ECDHE modes at the top of your cipher preference string.  If you value PFS over Windows XP users, then create a cipher preference string with only ECDHE modes.

Qualsys's SSL Labs has a great article on deploying PFS, and of course their checker will help you figure out which browsers will negotiate with which cipher suite.


In IKE, the "PRF" is subject to negotiation between the two involved entities. There are several defined PRF in use; most are HMAC, with MD5, SHA-1 or with one of the SHA-2 functions. At least two AES-based PRF have also been defined: AES-XCBC-PRF-128 and AES-CMAC-PRF-128. The role of the PRF is to serve as internal engine for key derivation and similar usages within the protocol.

The expression:

  the generation of a key based on modeled random oracle hash functions

means that a key will be generated by applying a sort-of hash function on some input, and the security of the process will be ensured if the hash function behaves like the abstract mathematical concept of a random oracle. The intuitive idea of a random oracle for key generation is that if you derive several keys from the same input set, with just minor variations (e.g. for a given input X and hash function h(), you compute h(X||1) and h(X||2) to get two derived keys), then nobody would be able to learn anything about any of the keys even if he knows all the others. The "random oracle" is the academic term which somehow means "perfect hash function".

(The mathematical details of the notion of random oracle are intricate, and I won't delve into more details here. The sentence you quote is mostly a private signal for cryptographers: it states that whoever wrote the text knows or pretends to know cryptography, and indicates to other cryptographers under what mathematical assumptions the security analysis has been performed.)


You are approaching the problem from an entirely wrong perspective.

Whatever is on the client-side is out of your control. Any determined enough person will be able to bypass whatever measures you employ. Instead, have your server control and validate the important data. There's no reason for game money to be controlled by the client unless it is a single-player game and if so, why bother?


Wordpress site redirects to different site when using https. Have I been hacked?

As there are other sites on the same server as your website  showing the same behaviour (like for example: http://annihilatethehero.com/ vs. https://annihilatethehero.com/) I assume you have your webspace from a shitty reseller who configured only one ssl-page on the server: The Page of the Shanto-Mariam University of Creative Technology

So any connection over HTTPS will lead to this page and the server doesn't even care for the domain in the request.

So I don't think your site or your domain has been hacked, it is just a misconfigured server. You can also see the page by visiting only the IP of the server with https: https://68.168.212.202/

Another sign for bad configuration may be the page you see when visiting the IP over http: http://68.168.212.202/cgi-sys/defaultwebpage.cgi

  If you are the owner of this website, please contact your hosting provider: webmaster@68.168.212.202


Your technical analysis makes sense, but one basic assumption is flawed. The purpose of hashing is not to help people who share the same password across many sites. This is a absolute no go and should neither be encouraged nor supported.

The main goal of hashing is protecting passwords against offline attacks. If an attacker is able to access the password hashes on the server, he should not be able to crack them offline and use them on the same site. Sure, if a user doesn't follow best practice and re-uses the password on different sites, this is even worse, but ultimately the user's fault.

Your approach, hashing on client side, opens the system up to a pass-the-hash attack, where you don't need to real password but can authenticate by sending the hash value only.

By stating, that the server never sees the real password, if the client hashes it, you are technically correct. But, when using this scheme, the hash actually is the password.


My client needs credit card details emailed to them, will an encrypted file work?

I believe the situation is a bit uglier than you may have realized.  Were I in this situation, I would invest myself in finding the wholesaler's competition!  I would want a wholesaler who provides either a service that can directly accept orders from your client's site or, better yet, a page that can be linked from your site to allow the user's to enter the information directly into the wholesaler's system.

PCI-DSS does not formally apply to your client except to the extent that the wholesaler requires them to comply.  You must understand that PCI-DSS is a contractual requirement between business entities.  It is not a law that everyone must respect.  You are not submitting the card data to a credit card processor, just to a merchant.  The wholesaler is probably in violation of its contractual responsibilities to its card processor, but that does not directly expose the wholesaler's clients (i.e. your client) to PCI specific requirements.

Having said that, the potential for legal action against your client by customers whose cc data is compromised may exist.  I am not a lawyer and this is not authoritative legal advice.  ALSO, independent of PCI, I believe every state in the US now has data breach notification laws that will require your client to notify customers of exposed data and provide credit protection for some period, usually at least 1 year, in the case of a breach.

So, PCI does not really apply, but you have to be careful how you handle all customer data. Now, let's discuss possible approaches.

Two encryption approaches suggest themselves: encrypt a file then emailing the file; using encrypted email using S/MIME.  Personally, I like the encrypted email approach.  An email can be constructed and encrypted in memory so the unencrypted data never lands on the server's drive.  Writing a file then encrypting it adds a layer of risk.

With S/MIME you will naturally use an x509 certificate with a public/private key pair for asymmetric encryption.  If you go with the encrypted file approach, I urge you to use asymmetric encryption rather than the much more simplistic symmetric encryption.  The big difference between the two is that an asymmetric solution on the web server would only hold the public key.  If the server were compromised, the attacker would not gain the ability to decrypt the messages.  Only your client, using the private key, could decrypt the messages.

There are several encryption solutions available.  One robust, mature and open source library is GPG.  It is also very well documented and versatile.  It could be used for either of the approaches I've described.


Burp not intercepting the intended traffic

I'm assuming you're NFC reader is a peripheral device?

Burp can be set up as a MITM but you'll need to direct any traffic from that peripheral to be aware of the Burp HTTP proxy if you want to intercept the traffic.

You'll have to review the settings for your specific device after setting up your Burp proxy.


USN Journal leaks information on exFAT-hosted files (in VeraCrypt containers)

Windows has many default functions that are aimed at common use and support but can become problematic in a privacy/security context.
Not only your example in Journaling, but many other functions may be a concern as well. For example, external drive connections, such as Thumb Drives, often save drive identities and top level directory filenames in shellbags encoded into the registry. This content can persist long after the device is removed.
Once encrypted volumes are unlocked and mounted, all the standard Windows functions apply, including malware scanning, with copy/export if unknown executable, of the contents.
Simply plugging a thumb drive into a Windows machine will result in a hidden directory with a GUID (Globally Unique IDentifier) being written to the drive. To be fair, Mac's do this as well.
Along related privacy/security lines, encrypted PKzip files maintain a clear text list of all of the filenames in the archive. Note that 7zip does not do this.
In short, if you feel you need a higher level of privacy/security, you may want to re-evaluate your choice of operating systems.


Is this authentication and encryption solution secure?

Your solution could be affected by the following concepts:

Do-it-yourself Cryptography

DIY crypto is an anti-pattern of secure software design. Most (>99%) attempts will fail. Nevertheless I respect your try! :-)
For example: Don't reveal the "passwordSalt", if you don't need to. It helps the attacker to crack the challenge. After one request an attacker knows the salt and has a challenge which could be cracked. The security relies only on a strong password. The attacker can crack the password offline. This should not be the case for online services. I rate this as highly insecure.

Perfect Forward Secrecy

The key for the encryption (serverside generated token) should be calculated on both sides (client and server) using Diffie-Hellman Key Exchange or similar. If someone recorded the traffic and gets the user password, he is able to decrypt the token and then decrypt the whole traffic, afterwards.

Steps 13-16 not needed

If the client can decrypt "passwordSalt + encryptAes(token, passwordHash)" successfully, the server had to know "passwordHash", therefore the user password.

This list is not complete, as several other weaknesses could be present.


Why does Facebook bother comparing old and new passwords?

Because if Facebook can algorithmically produce similar passwords, then so can a password cracker.

The sequence could go like this:
Password compromised -> user changes it to something similar -> new password compromised algorithmically by trying similar passwords to known previous one.

Also, imagine a scenario where an account is being specifically targeted by an actual human being. The attacker may know previous passwords or have an idea what they roughly could have been (e.g. the account owner's ex romantic partner or something). In this case, a password that was similar to a previous one would be more likely to be guessed.


How are malware able to start on boot on windows without administrator rights?

Find a Service which runs an executable which a user can overwrite (Hint: Installed software that has its own updater usually fits the bill.)
bitsadmin (see this example) can run on schedule or on event, and call a handler program, specified by a user.

  if a malware doesn't have administrative rights? How can it defend against a user that removes its registry key?

Of course, either of these can be undone by a user just as they can be done by a user, but they're subtler than Run keys and more likely to avoid notice.


Depends on how many plaintext-ciphertext pairs you can collect. Potentially, you can infer what mode (e.g. maybe ECB) is used.

On most occasions, though, known plaintext attacks (KPA) are weak against properly designed ciphers as those are designed specifically to thwart at least that type of attacks. This means that collecting and comparing the pairs would yield no information as to which cipher and the encryption key were used to encrypt the text.

So sorry, unless it's a simple XOR with constant keystream, you are unlikely to find out the exact method used with only one text pair.


In IIS 7 (and 7.5), there are two things to do:

Navigate to: Start > 'gpedit.msc' > Computer Configuration > Admin Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order (in right pane, double click to open). There, copy and paste the following (entries are separated by a single comma, make sure there's no line wrapping):

  TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256

Run the following PowerShell commands as administrator (copy-paste into Notepad, save as 'fix-beast-in-iis.ps1' and run with elevated privileges):

#make TSL 1.2 protocol reg keys
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"

# Enable TLS 1.2 for client and server SCHANNEL communications
new-itemproperty -path     "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "DisabledByDefault" -value 0 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "DisabledByDefault" -value 0 -PropertyType "DWord"

# Make and Enable TLS 1.1 for client and server SCHANNEL communications
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "DisabledByDefault" -value 0 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "DisabledByDefault" -value 0 -PropertyType "DWord"

# Disable SSL 2.0 (PCI Compliance)
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" -name Enabled -value 0 -PropertyType "DWord"

Once you've run the script, you can run 'regedit' and make sure the keys in the script were actually created correctly. Then reboot for the change to take effect.

WARNING: Notice I didn't turn off SSL 3.0- the reason for this is due to the fact that, like it or not, there are still people out there using Windows XP with IE 6/7. Without SSL 3.0 enabled, there would be no protocol for those people to fall back on. While you may still not get a perfect on a Qualys SSL Labs scan, the majority of holes should be closed by following the previous steps. If you want absolute PCI compliance, you can copy the lines from the Disable SSL 2.0 section of the Powershell script, paste them at the end of the script and change them to the following:

# Disable SSL 3.0 (PCI Compliance)
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -name Enabled -value 0 -PropertyType "DWord"

Then, when you run the script, you disable SSL 2.0, SSL 3.0 and enable TLS 1.1 and 1.2.


Yes, SSL/TLS also protects you against spoofed DNS answers (at least for those connections which actually use TLS). The reason behind this is that a client has to compare the hostname you enter (in the Browser URL bar) with the hostnames listed in the certificate.

If you now get redirected to a wrong IP address this host has either a different hostname in the certificate, or it contains a hostname where it does not get CA signature for. Both will be flagged as a problem by the browser. You can also not steal a certificate from a valid host, because in order to use it as a server you also need its secret key.

This however only works if all hundreds of CAs of this world play by the rules and all clients do the checking.


Repercussions on Google account used to access a compromised service

The google login uses OpenID Connect and therefore does not expose Alices credentials to the service.

Google handles the authentication process and passes the information, that this is indeed Alice to the service provider in the form of a token.

However, if Alice was tricked to enter the password for her google account in a phishing-form on the compromised service, it's still possible to get compromised.

Although it was a different question, Jens Erat provided a great explanation of the protocol involved.


A smart card sounds like what you need. It's designed to let users decrypt whatever data they want with its onboard key for as long as they have it, but it doesn't let them extract the key itself from it. Note that this won't prevent users from leaking the decrypted data afterwards; this would be equivalent to effective DRM and is basically impossible.


Generating Web Application Security Profile

You might have heard of this.There is a mod_security rule set provided by OWASP. This rule set is to protect from the top 10 attacks listed by OWASP(you can download from OWASP website)


A late response, but this is a long-standing bug in Chrome.  Chrome doesn't update the security indicator in the address bar before showing the basic auth dialog (though it does validate the security correctly, so an expired certificate is correctly marked).

https://bugs.chromium.org/p/chromium/issues/detail?id=700748
https://bugs.chromium.org/p/chromium/issues/detail?id=667021 (see also 395050)


How to import primary secret key from backup into GnuPG?

The file you're trying to import does not contain the actual private key, as indicated by this line in the output of gpg --list-packets:

gnu-dummy S2K, algo: 3, SHA1 protection, hash: 2

The special "dummy" S2K algorithm is applied when GnuPG actually exported a secret key stub to still enable using secret subkeys, but having an offline primary key (on another computer, a disconnected thumb drive, an OpenPGP smartcard, ...). This key stub is also what you observe in the --list-secret-keys/-K output:

sec#  4096R/53A3B420 2016-04-06


I Developer a script for filter the sfportscan log and integrate it with OSSEC

SNORT(sfportscan) -> portscan.log < filter.py > portscan-filter.log < OSSEC Regex >

#!/usr/bin/python
a = ""
f = open("/var/log/snort/portscan.log","r")
s = open("/var/log/snort/portscan-filter.log","w")
while 1:
    where = f.tell()
    line = f.readline()
    s.seek(where)
    if line[:4] == "Time": a = line
    elif "(portscan)" in line:
         a = a.replace("\n","")
         line = line.replace("\n","")
         ray = ','.join([a,line])
         print (ray)
         s.write(ray+"\n")
         a = ""
    else:
        pass
f.close()

Output: Time: 01/02-12:34:56.006648 ,10.147.160.122 -> 177.124.192.123 (portscan) TCP Filtered Portscan

And i made this Regex for integrate with decode OSSEC rule: (\S+) ,(\d+.\d+.\d+.\d+) -> (\d+.\d+.\d+.\d+) (\(\w+\) .+)


Cookie-to-Header CSRF protection vs CORS

CORS relaxes the same-origin policy. If a browser does not have CORS support, it enforces the same-origin policy. So evil.com can not read the CSRF token from api.com.


Writing payload into android device listening for adb debug messages

Yes. Debug mode or USB debug, depending on OS version.


Why is linux filesystem considered DAC and not MAC

I don't think the granularity of permissions that can be achieved is relevant here. It doesn't matter if permission can be assigned to specific users, it matters which users can change permissions. Perhaps the DAC article is more clear about this:

  In computer security, discretionary access control (DAC) is a type of
  access control defined by the Trusted Computer System Evaluation
  Criteria[1] "as a means of restricting access to objects based on the
  identity of subjects and/or groups to which they belong. The controls
  are discretionary in the sense that a subject with a certain access
  permission is capable of passing that permission (perhaps indirectly)
  on to any other subject (unless restrained by mandatory access
  control)".

(emphasis mine)

The key difference between MAC and DAC is that with DAC someone who has certain permissions to a file is able to alter that file's permissions.

  The term DAC is commonly used in contexts that assume that every
  object has an owner that controls the permissions to access the
  object, probably because many systems do implement DAC using the
  concept of an owner. But the TCSEC definition does not say anything
  about owners, so technically an access control system doesn't have to
  have a concept of owner to meet the TCSEC definition of DAC.

  Users (owners) have under this DAC implementation the ability to make
  policy decisions and/or assign security attributes. A straightforward
  example is the Unix file mode which represent write, read, and execute
  in each of the 3 bits for each of User, Group and Others. (It is
  prepended by another bit that indicates additional characteristics).


Setting up Windows laptops to require a smartcard for unlocking

Assuming the laptops to run under Windows, you would need the following:

a PKI solution to initialize and manage smart cards; each smart card will contain a private key and the associated certificate;
to enable smart card logon so that users open a session on the laptop with the smart card, instead of a password (the smart card itself will require entry of a PIN code);
to set a local policy which locks the laptop when the card is removed (that one is easy);
to activate certificate-based client authentication on the HTTPS server (see this if the server is IIS).

I have done all of this with that kind of cards; they come in several form factors, including as "USB keys" (actually USB-based smart card readers with an embedded smart card), which are convenient since all laptops have USB ports. The biggest cost is the PKI; not really the software, especially since there are free PKI (and you will want to have a look at this, by the way). 95% of PKI is procedures, i.e. people who spend some time doing things and checking that they did it right and auditing that other people did things right.


Is it safe to open ports 80 and 443 in a home network

Generally the best practice for this is to have a DMZ.  The DMZ is a subnet for any servers (like web servers) which will service requests from clients off your network.  In addition any databases or other devices/servers that are needed to provide services for the web servers should live in the DMZ (preferably each on their own VLANs).  These external facing servers sit behind a firewall (which only allows proper http or https traffic to go to your DMZ).  Additionally, if you are protecting sensitive information I would use a Web Application Firewall (WAF).  There are good free ones out there.  The WAF will inspect the http/https traffic and filter out a huge collection of known malicious http/https sql etc attacks common to web servers.

One major purpose of this design is to limit the damage in the (reasonably likely) event that somebody manages to compromise your web server.

note* The DMZ should not be able to initiate connections into your internal network.  You only want internal to DMZ traffic (not DMZ to internal).


What pages are vulnerable to SQL injection?

Do you trust all of your authenticated users completely? Including that they won't have their accounts compromised by attackers? It's bad if an attacker gets access to an account, but far worse if they can then leverage that to steal the rest of your database.

For your second point, the example you've used would not be vulnerable. However, take care with more boundary cases such as

$query = "SELECT * FROM tableName WHERE secret='".dbquery("SELECT secret FROM otherTable WHERE id=3")."'";

If it was possible to insert a payload into otherTable in the secret column for record with id 3, this would be vulnerable to Second Order SQLi, even if the insertion routine used prepared statements.

As per comments:

SELECT * FROM tableName WHERE secret=(SELECT secret FROM otherTable WHERE id=3)

is executed within SQL, so not an issue. The problem occurs when data drawn from the DB is considered trusted at the application layer, and used in later queries.


How does a trusted maps.googleapis.com in CSP enable an XSS vulnerability? (JSONP)

Consider if something like this was attempted by an attacker injecting XSS:

<script src="https://maps.googleapis.com/foo?callback=alert"></script>

This would execute the foo function from the Google APIs JavaScript SDK, and upon it's return would call the alert. This demonstrates that an attacker would be able to inject inline code into the page, which would be executed. Therefore XSS is achieved which bypasses the blocking of unsafe-inline code.

Of course, what can be called would depend on the arguments passed and how exactly Google sanitise the callback parameter. It appears that CSP Validator just has a simple rule to flag these in the form "does the domain in the CSP support JSONP?" which does not take into account how the callback is executed.

This seems fair, as CSP Validator will never know if any code alterations on the external domain ever introduce or patch such vulnerabilities so I think it is correct that this is flagged.


If a CVE lists two particular affected versions, and I use a version between those two, what's the next action for determining vulnerability?

The researcher may only have been able to test those two versions, there isn't much point in speculating. Depending on which distro you use the patch may have been back ported without a change in version numbers.

The next step is to make sure you use the latest version supported by your distro and check their change logs for the package to see if it has been patched. If you want to verify the patch as effective you would have to attempt exploitation. As there is no readily public exploit you can use to test you would have to invest time to try to develop a poc or reverse engineer the patch.


Tor: Is a diffie-helman key exchange being done over reciepient of traffic?

No, the key exchange is done between the client and each relay. This is the general technique behind onion routing. For the modern Tor protocol, the client will exchange a symmetric key (AES128) with three relays using ECDHE (not DHE), specifically using Curve25519. A message being sent from the client will be encrypted three times with each key, and each relay will strip a single layer of encryption. Once the message reaches the exit relay, there is only one layer left, the layer encrypted with the key known by the exit. The exit decrypts it and sends it on its way.

Also note that your diagram is incorrect. The SOCKS protocol is not used to connect to the first relay (the guard), but rather to allow a local program on your computer to connect to your Tor client (usually over localhost). The protocol used to connect to the first relay is the Tor protocol itself.


Preventing User Enumeration on Registration Page

Since the username is the public part, it isn't the end of the world if it can be enumerated, however if you really do want to avoid this, the easiest thing is to have them use e-mail address as the username. Then you simply say that you sent a link to the e-mail no matter if they have an account already or not.


If a digital camera can be "hacked" in the ransomware sense, how best to protect it?

From the OP's link… or more precisely from the security report the tweet is linked to - Check Point Research Reveals Modern Cameras’ Connectivity to Wi-Fi Make Them Vulnerable to Ransomware and Malware

  Here are some things camera owners can do to avoid being infected:

  Make sure your camera is using the latest firmware version, and install a patch if available.
  Turn off the camera’s WiFi when not in use.
  When using WiFi, prefer using the camera as the WiFi access point, rather than connecting your camera to a public WiFi network.

That third point is the one - if your camera is the access point, then before you can even start to try to hack it you first need to hack into the access point. WPA2 is not impossible, but certainly not easy to hack. Once past that you would need to try to side-load the specific hack for that specific model of camera.

All the time you were doing this you'd have to be within 15m of the photographer.

Defcon does this kind of thing every year - it exposes weaknesses to make manufacturers change their practices, long-term. The thing is that you get good brownie points for finding a new exploit. It doesn't have to be one that's easy or even likely, it just has to be possible.
Cue crowds of cheering pen-testers.

As with all good white hat hackers, CheckPoint first told Canon about the exploit they had found & didn't make it public until after it had been patched.
Canon - Regarding the security advisory for Canon digital cameras related to PTP (Picture Transfer Protocol) communication functions and firmware update functions


Best practices for storing and submitting browser fingerprints to secured endpoints

fingerprinting is used for anything but security, so do not use it for such a purpose.

Since you are using openresty, you can in fact add security to your session handler lua-resty-session has several different options as to where store the session data.

When you read pluggable-storage-adapters you see a table of storage adapters.

For your purpose I would suggest you implement one with Extra Security and implement HMAC.

This will make sure that the session data stays on the server, and that the client only has a HMAC token they can not alter without losing the session.

For additional protection you can add a little code to the authentication Lua to make sure the session is invalidated when the ip source changes.

I hope this answers your Question.

-- Including a comment I made to this awnser.

fingerprinting can be used to enhance the certainty of a specific user, it is however unsuited to replace other means of identification.

(see it like an ID check at a customs officer, your passport Identifies you, its number (and the check done by the automated systems) validates the document is real. and the image of your picture can be used to validate yourself to the officer. So in total while there is only 1 primary carrier of authenticity (the passport) there are many checks done to validate it.

Each check adds to the certainty that the person is who he/she claims to be.
and as part of a authentication scheme you can add the fingerprint as additional information to proof identity. But it should never replace other proofs as its to generic, and to easily to forge or extract through other means.


Linux is Linux is Linux. Quite a few commonly used tools (nmap, wireshark etc) are already in the package repository. Those that aren't, you can compile yourself.

Will it be more effort than simply spinning up Kali or Debian? Sure. Is it perfectly viable? Definitely.


What are the different types of RFID shields for cards? (Some seem to block 1 side only, some affects all nearby cards regardless of side, etc.)

To do what you want to do, I would not use an active blocking device like your video shows. I would use a blocking sleeve for the cards you want to protect.


Can't get into Damn Vulnerable Web App with Hydra even though correct password is supplied

If I read the source for login.php correctly (at https://github.com/RandomStorm/DVWA/blob/master/login.php) the page does a check for an anti-CSRF token. If it is not there, you will get a redirect back to the login page. So you will need to include that token in your tries.

I won't give it away completely but check for a hidden parameter called user_token in your login page.


Am I being used as a conduit for cyber-attacks against my friends?

Let's, for fun's sake, assume that the hugely likely answer, that this is  pure coincidence blown out of proportion by selective perception, is wrong.

Let's also assume that you're innocent of any wrongdoing.

The most likely explanation (but orders of magnitude less likely than the coincidence theory) then becomes that someone who knows all three of you, lets make her a gal named Mal, is trying to create conflict between you three.

Now, since your friends immediately thought of you as the culprit, and you don't mention anyone else you suspect, Mal must be incredibly devious, because she managed to conceal her dislike of you and your relationship with your friends from all of you, while investing criminal energy to damage you.

Mal either owns an iPhone 7 Plus, or is motivated to camouflage as an iPhone 7 Plus and capable of doing so. None of these options make sense. More on why later on.

If Mal really wants to create conflict between you, trying to access your friends accounts from some random place in NYC seems an awfully roundabout way to go about it. If you can't think of anything more likely to succeed than that, you're probably a stock fish. Be that as it may, framing you would work much better if the login attempts could be shown to come from one of your IP addresses (your phone or your home network). Still, there'd be no easy way to prove that a given IP address was held by you without contacting the police, who certainly wouldn't waste their time and act on a complaint about attempted logins on the internet, so this whole framing business is not just hugely unlikely, but, again, completely stupid.

But let's say that Mal, being almost as stupid as she was devious, didn't realize the whole idea was stupid, and so would be someone you knew, and who had access to your home wifi network, one of your devices that connected to it, or your phone, without you realizing so.

She could either be physically present in NYC, but hiding from you (since otherwise you'd probably have noticed her hanging around your place) or, in addition to being devious and stupid (for thinking up this harebrained scheme that won't work and actually wasting time on it), she would also need to be a talented hacker who managed to hack into one of your devices, again without any of you knowing about her hacking talents.

Now if Mal lived in NYC and didn't own an iPhone 7 Plus, OR if she hacked into your devices, she would also need to camouflage as an iPhone 7 Plus. You'd have to wonder why she would want to camouflage as a device you don't own if the motivation was to frame you and she was going through the trouble of using your network or one of your devices to accomplish it.

If she did own an iPhone 7 Plus, you'd need to wonder why she went through the trouble of attacking your friend's accounts from that. She'd need to know that pretty much the only thing iCloud, Facebook, Google etc tell you about strange login attempts is the perceived location, time and the device of the attacker. If she didn't do her account hacks from your network, she'd have to realize that an attack that came from an iPhone 7 Plus, which you don't own, at a time when you weren't home, wouldn't plausibly frame you if the only other piece of information was that it came from the same city you happened to live in; a city that has, apart from you, a fair number of other people in it.

I take it you don't know anyone who fits Mal's profile.

As you can see, this whole train of thought derails at pretty much every curve. I'm aware this isn't a rigorous ad absurdum proof, but you have to admit that it makes the other explanation, that this is simply a coincidence, look much, much better.


Isn't the behaviour of the switch to flood packets when it's MAC table is still empty dangerous?

Not, it's not dangerous because the switch will broadcast only the first packet, not all the next packets.

The status of the switch internal tables will be like this:

On the first instant, the table is empty, so it works like a hub, broadcasting everything
When ComputerA (plugged to port 1), sends a packet to ComputerB (plugged on port 5), the switch will broadcast the packet to everybody, but create a entry on its table: ComputerA is on port 1
ComputerB responds, and the switch will send the package to port 1, and create a new entry on the table: ComputerB is on port 5
Every new packet between ComputerA and ComputerB are sent directly, without broadcast.

Even if ComputerB is the gateway, ComputerC will be able to get only one packet sent from every other computer on the network.


Are there any good brute force programs in C#?

I don't know any particular brute force in C#, but having worked in both C and C# (and inferring that you know C# from your question) I think with a good reference you should be able to jump into C. You will of course need to be very careful with garbage collection (malloc, etc.) and it will require learning procedural vs. object oriented coding but it's doable.

Here's a good thread: https://stackoverflow.com/questions/4002442/learning-c-from-a-background-in-c-sharp

One of the recommendations is The C Programming Language which is a classic. For something much lighter and very funny I'm a fan of Dan Gookin's C for Dummies which is light but still informative.

Good luck!


If you simply embed content from site A (dangerous) into site B (innocent) somebody watching the traffic of the user will see requests made to site A, i.e. not what you want.

Instead you need to replicate the full site A into site B so that site B only embeds resources from site B and also the final form submission has to submit data to site B. This can be done by making your server at site B a proxy which internally forwards (not redirects!) every request to site A. Be sure to use no fully qualified links which include the name of site A though  but only site-relative or site-absolute links (i.e. links without explicit domain).


Are CVE identifiers assigned for proprietary software packages?

Yes, they are also assigned to proprietary software. An example would be Oracle Database, which has a variety of CVEs assigned to it.

To request an ID, check the CNA coverage table. If the vendor is listed, request from them. Otherwise, request directly from MITRE.

The process of the vendor may or may not include requesting CVEs themselves, so when contacting them let them know that you already requested one or are planning to do so.


There is an extention made for OpenVPN for OTP (One Time Password).
This extention includes Google Authenticator software tokens.

https://github.com/evgeny-gridasov/openvpn-otp


Have questions about received security scan

First, as strong as Fortify is for static analysis, it still doesn't understand your application or deployment model so it has to make guesses sometimes. And when in doubt, Fortify says something is a problem. So you will have many false positives that you simply need to ignore. You can do this by setting the Analysis field to Not an issue in Audit Workbench or the SSC. Fortify will carry this forward to future scans so that you never need to pay attention to this issue again.

Unprotected File - It's hard to be certain without seeing the code but, based on your description, it sounds like this isn't a problem. Fortify is correct, these files are unprotected, but they're supposed to be that way. So mark it Not an issue and move on.
Password Management: Insecure Submission - The problem here is your use of GET instead of POST to do the login request. GET parameters are passed through as part of the URL after a ? character. URLs have the nasty tendency of getting recorded in logs and such. So passing a password, or any other confidential data, via a GET request is considered a privacy exposure. You should change the request to a POST on the client and/or the server, depending on your webapp framework.

CWEs are entries in the Common Weakness Enumeration. They are a list of common programming and deployment mistakes that lead to security flaws. Fortify displays them to help you understand the problem it found. For example, the unprotected file issue might show up as CWE-306: Missing Authentication for Critical Function. You can just google them to find specific ones. If you've not already read the CWE-25, it is probably worth your time to do so. Those issues tend to come up often in application security.


Can a running interpreted program cryptographically prove it is the same as as a published source code version?

While it is not possible to do so at run time, applications can be verified at load time (FIPS compliant OpenSSL does so).

  Said another way, is there a way to ensure that the commands/code executed by such a program are all and only the commands and code specified in a publicly disclosed repository?

Possible but not the way that you imagine. One of the requirements of a trusted software is that it needs to be verifiable. It can be verified either manually or using static analysis. If a code is not verifiable, then you can't really ensure that the code that you are running is actually the code that you see in a repository.

When a library is loaded into the memory, you can run it's signature against a known good signature of the library and ensure that the library that is loaded is indeed the one that you got from a repository.

How do we verify?
Well, there was a time when the verification was done manually by code review and generating all possible test cases but as systems grow larger, this becomes more and more difficult. There are several static analysis tools available that ensure that a source code doesn't have any possible program flow that will cause a failure or an unexpected scenario. (Coverity has a free static analysis service for Open Source projects).
Once we have ensured that the code cannot be misused at run time, our job will be to ensure that it is not tampered with in our machine.

How do we ensure that it is not tampered?
There is a concept of secure boot. What it does is that every time a module is loaded, it verifies the signature of the module against a known good value and if it is fine, then it lets the boot to continue otherwise the boot fails. Similar concept is used over here. When a program is loaded, we compare the hash of the loaded module against a known good value and ensure that it is indeed the program that we received.

This way, ensuring that the program cannot be misused at run time and then ensuring that a known good program is loaded, we get an assurance that the program is indeed what we want.


In what ways do some banks inadequately advise their customers on online security?

Banks have been urging the use of debit cards for years, but the policies around reimbursement after a fraudulent transaction are widely variable. It's one thing to have a fraudulent transaction sitting on a credit card statement, but it's quite another to have actual cash missing from your checking account and not be able to pay your rent. I always encourage people to use a good old-fashioned ATM card with no MasterCard/Visa logo; at least that way there's a PIN protecting you.

The notion that the "security picture" during login protects you from an imposter bank has been thoroughly debunked, and is a vestige of the previous FFIEC standards.

Banks tell customers that using security tokens like SecurID or Vasco can prevent malware-based attacks, but the reality is that the malware just sits there on the computer waiting for you to enter an OTP and then sends it to a waiting attacker in realtime. No protection there.

Finally, while login security is important, it's not enough. Most online banking fraud is traceable to malware, and the worst stuff just sits there and waits for you to log in before sending through unrequested transactions. The login can be as secure as you want, but unless you secure the transaction itself, you're still vulnerable.

One last thing - banks are still telling users that their SecurID tokens are completely safe. This is likely incorrect. If the attackers in March made off with all of the seeds, then the tokens are basically worthless. If they made off with only a subset of the seeds, the bank would need to find out for sure if their seeds were stolen. I've yet to hear any bank be able to make a claim on this point one way or another, so I assume any SecurID manufactured before this summer is owned. This doesn't apply to Vasco or anyone else, just to RSA.

Many banks simply do not understand these points, at least outside of their security teams, so the actual advice given out by customer service reps is often wrong on these points. I don't think it's necessarily the banks' faults; you can't expect every customer service rep to be a data security guru, but it does mean that the banks have a responsibility to deliver a secure enough system that bad advice from customer service doesn't matter.


DKIM by itself does not protect against spoofing of the From: field in the mail header (i.e. RFC822.From). It only adds a signature which shows that significant parts of the mail header were not changed and that the mail passed through the mail server responsible for a specific domain.  In your specific case the DKIM signature shows that the mail passed through the mail server for spammailer.com but not through the mail server for ibm.com as proper mails from ...@ibm.com would probably do.

The protection against spoofing of the From: field is only added by DMARC. Providing that the mail domain has a DMARC policy (as ibm.com currently does which dig txt _dmarc.ibm.com shows) the receiving system can check if there is an aligned DKIM signature or SPF result. Aligned regarding DKIM means that the domain given in the from From: field matches the domain of the DKIM signature (either exactly or by allowing sub-domains, depending on the DMARC policy).


WPA cracking with Crunch, JTR & Aircrack

crunch 8 26 abcdefghijklmnopqrstuvwxyz0123456789 | aircrack-ng psk-01.cap

is an example of what you could try.


A protocol for encrypting the data on the server, but with a password on a mobile device

Before designing a protocol, we need to make an important decision: do we trust the server?

If we do, the design can be quite simple: HTTPS would be used for communication encryption, and disk encryption would be used for data encryption, and there would be no encryption in application code. All access control decisions like "is this data approved" and "is this third-party authorised" would be done as database records, enforced by checks in application code.

This is the standard approach, used by many thousands of client-server applications, including high-value finance, military, aerospace and healthcare.

In some cases, it is possible to avoid trusting the server. For example, many password managers encrypt your password vault with a master password on the client, and the server only processes the encrypted vault. However, this gets harder with more complex applications, especially when multiple parties are involved. There is a major risk that a scheme will only add the appearance of security, not true resistance to attack.

For example, in the scheme you propose, the server has transient access to the one-time keys. So a hacker (or malicious sys-admin) could harvest data over a period of time. To rectify that I recommend using public-key encryption:

Each user of the system would have a private key that only they know, and a public key that is shared with the server and other users.
When a third-party creates a record, they encrypt it with a random key (like the OTK), and encrypt the OTK with the recipient's public key. The server stores this in a temporary area until it is approved.
A user approves a record by signing a hash of it with their private key. The server then puts the encrypted & signed message in the database.
To share a record with a third party, the user encrypts the OTK with the third-party's public key.

Even with all this, the server can potentially cheat by substituting a user's public key with its own. You can partially mitigate that with external monitoring, or an external certificate authority. Ultimately, this is a great increase in complexity for what is probably just a marginal benefit. That's why the standard pattern is to just trust the server.


No. It is not secure to restore the data without taking steps to ensure that the data was not corrupted in ways that can lead to more security holes.  It is also unlikely that upgrading from 9.4 to 9.6 is going to make any difference, and might actually complicate the restoration.

Many attacks involve the altering security information stored in the database.  Even if you don't have such tables, it is just as common for attackers to embed code in what would normally be considered data and exploit security holes in the boundaries between code and data.

The correct way to proceed is to take a dump immediately prior to the attack and compare it with the last dump.  This takes some skill, and you may have to assume a worst case scenario if you can't ascertain from audit and log files when the attack began.

Try to find ways to compare the before and after dumps, eliminating legitimate changes with each compare iteration.  You will eventually find nothing, in which case you may have to take a risk of importing the data or restore to the last known good backup and live with the loss.

It would be better if you could use the compare and log and audit information to reverse engineer (best case) or determine the likely breadth of (less sure) the attack.

As unhappy as the truth is in this case.  This IS like rocket science.  You may need to ask more questions.  Of course, much depends on how sure you need to be that you've cleaned all potential threats from the system, which depends on how critical the data and the user accounts are.


Revoking signing keys: do they still work afterwards?

Can I revoke the signing subkey using the public key or do I need a copy of a private key as well?

No, you always need the private primary key for all key management operations (subkeys, user IDs, ... are all bound by signatures of the private primary key). Consider it was possible to do this using the public primary key, everybody would be able to revoke your key (as the public key is -- well, public).

  Should I delete the key from my keyring to have a clean list of keys or should I keep the revoked key (and why)?

Leave it there. The public key will get resynchronized anyway as soon as you update your key from the key servers. And the public key also carries the revocation information.

  How can I inform friends/colleagues about it? Do I email every one of them or is there a more massive approach? If they don't receive the
  information, will they see for example my emails as "TRUSTED Good
  signature from ..."?

"It depends". Some clients will automatically fetch the updated key when they receive the first mail signed with an unknown (sub)key, others won't.

If you're just doing key escrow and exchange keys in advance, consider creating the new key some weeks in advance to allow people fetching them up. I wouldn't bother people when creating new subkeys (especially signing subkeys) without a real revocation reason, they will realize they're missing the new key as soon as they receive a signed message. As you're taking advantage of subkeys, if they trusted your old key, they still trust your new one (trust and validity are assigned to primary keys, subkey validity is derived from the primary key).

If you suspect or are sure your private signing subkey got into the hands of an attacker, I'd indeed go out and mail those I signed/signed me and/or publish this information at relevant places (for example, if you're signing software).