Please rate this SQL injection prevention strategy

This suggests that their sanitization practices are not very targeted.  In particular, you should never have to sanitize a password.  Passwords should immediately be hashed and only the hash should ever be stored.  As a result SQLi via password field should be impossible.

Now normally defense in depth suggests taking extra steps for security is a good thing, even if it seems redundant.  So a naive answer would be "they are being careful about security here, even if it is potentially unnecessary, so what's the problem?".  The problem is that unnecessarily removing characters from passwords (presuming it didn't actually break anything) makes the passwords weaker.  If their system properly "cleaned" the input both when the password was stored and when the user logged in, then the login would work normally but a password of "my--password" would presumably turn into "mypassword" before hashing.  As a result, the cleaned password is more crackable than the original.

The other issue is that the way they worded it suggests that they have a sanitization script that just blindly "cleans" everything.  This is really the lazy man's way to do security.  I've seen plenty of systems that use that approach, and in my experience it usually means that the rest of the security isn't really well thought out.

Finally, it really is a useless security measure, and steps which make things look good without actually improving security don't help anyone.  The reason why they are removing a double dash is because in SQL this is a comment, and as a result it is sometimes used as part of an SQL Injection attack.  Stripping out the comment characters isn't a very effective method for defeating said SQLi attack.  They need to reject such requests all together.  They also better be using prepared statements properly, in which case stripping out double dashes is doubly useless.

It is certainly no excuse for a bug: that just means that they failed to properly implement a less-than-ideal security feature.  Hopefully they made that comment to you as a "thanks for pointing out this bug so we can fix it".  Even if they want to keep their "cleaning" algorithm, it shouldn't break anything.


A DDoS attacks basically means the connection to your computer is saturated. There are several ways to do this but the result is the same: nobody can access your router and you may possibly not be able to go on Internet (roughly speaking).

No hacking is involved, once the DDoS stops you recover (you many need to reboot your router). So this is not "hacking" as per the movies, just a way of blocking access.

You may see some logs on your router (if you have any) but they may not be obvious. If you see a lot of traffic coming in it may be a DDoS. You may also not see much in the logs, it really depends on the attack.

If you are a home user you can file a complaint with your ISP but basically you need to wait until it is over. If this is repeated then you definitely should talk to your ISP (you cannot do anything yourself to protect against a DDoS).

Since you see that there are strange activity within your LAN (short of lack of Internet access) then it may be that this is not a DoS. Your WiFi may have been breached but this means that the attacker is nearby (as opposed to a DoS which can be done from the other side of the globe). Your first measure is to make sure you use WPA2 (see the  configuration of your router) and a looooong password.

If your internal network was compromised (ie. someone connected to your WiFi and possibly hacked other devices in your LAN) then the best thing to do is to reinstall the OS from scratch (particularly MS Windows and Linux).


3G Femtocell at home: can anybody connect, and is all traffic encrypted?

Whether the traffic is encrypted it's up to the femtocell manufacturer. You haven't provided much details, so I can only suggest you pull out wireshark and see what happens. Most likely traffic should go through via SSL, although I won't be surprised if there was no mechanism for updating CRLs and/or maintenance and open ports on the cell itself.

If I were to implement it, a low-cost solution would be to put a self-signed certificate on the box. The chances of somebody breaking into the hardware, stealing the certificate and using it for impersonating MitM attacks are small and if somebody is so well intentioned there are better devices such as stingrays which are less apparent. I've mentioned the need to stay low-cost as these devices are produced with tiny margins and often subsidised by the mobile operator.

Regarding your second question - whether anybody can connect to the device - the answer is both yes and no. When I asked my provider to set me up with a femtocell they asked for my mobile number and I suppose they set up the cell to recognise my IMEI - and since the device has no 'control panel' and it's behind my home router as NAT I assume there is some kind of ACL the device pulls remotely to see who is allowed to connect and who is not. Therefore, anyone authorized can connect, and this is probably defined server-side. Unfortunately I do not know enough about GSM standards to be sure how this is done in detail.

Lastly, regarding whether a phone has access to the local LAN, in the device I use this is not the case. In fact, I can "go online with 3G" through the femtocell and my phone's IP is of the mobile provider, not of my ISP. Therefore all traffic (data and voice) must be simply sent over the SSL tunnel to the mobile operator, which then takes care of routing it accordingly. I'm again assuming that, given the low cost of the device, a mobile operator has no interest in setting up complex routing policies to let data traffic go through a customer's LAN. This would also reduce helpdesk costs, as dealing with a home network might be very complex.


Is it possible for a name server provider to hijack MX records?

Yes, your registrar can hijack not only your MX records, but your entire DNS.

Not only that - but they can then proceed to intercept mail sent to your domain, get a valid CA-signed SSL certificate for your domain, and host a site for your domain using the trusted SSL certificate.  And DNSSEC won't prevent any of this.

One of the primary functions of your registrar is to register the nameservers for your domain.  For example, if you do a whois lookup for stackexchange.com, you'll see that the registrar for stackexchange.com is eNom, LLC., and that the nameservers for stackexchange.com are hosted by Google Cloud and Amazon AWS.  So, the DNS for stackexchange.com is handled by Google Cloud and Amazon AWS.

In the example that you gave in your question, cheap-unsecure-domains is the registrar for yourdomain.example.  With cheap-unsecure-domains, you specified Cloudflare's nameservers as nameservers for yourdomain.example.  So, DNS for yourdomain.example is handled by Cloudflare's nameservers. Then, in Cloudflare's control panel, you setup your DNS records for yourdomain.example, including your A records, MX records, etc.

So if cheap-unsecure-domains wanted to intercept your mail - they wouldn't need to hack into your account at Cloudflare to change your DNS records.  They would simply change the nameservers for yourdomain.example to their own, then create MX records for yourdomain.example in their nameservers to point to their own mail servers.  Then, they would start receiving mail sent to your domain.

Interestingly, they could start receiving mail for yourdomain.example securely using SMTP STARTTLS, without even getting an SSL certificate for yourdomain.example.  They could just use their own certificate.  See https://blog.filippo.io/the-sad-state-of-smtp-encryption/.

Now, things get more insidious.  They can start receiving mail for hostmaster@yourdomain.example (or admin@yourdomain.example, or any of the other designated approved email addresses used for SSL domain validation).  Then, they can request a SSL certificate for yourdomain.example from a trusted CA, and when the CA sends the verification link to hostmaster@yourdomain.example, they'll receive it, and the CA will issue the certificate.  Now, they can setup an A record for www.yourdomain.example, and run a site with a valid certificate for www.yourdomain.example.

At this point, you might be wondering - can't this type of attack be prevented using DNSSEC?  The answer is no.  DNSSEC records are stored in the DNS for the domain.  When the registrar changes the nameservers for yourdomain.example to their own, the DNSSEC records that you created for yourdomain.example are gone, along with all of the other DNS records that you created.  See https://moxie.org/blog/ssl-and-the-future-of-authenticity/ for more info.


When the match is unofficial, how relevant is the information ?

To cite from Sanesecurity: False Positives:

  UNOFFICIAL means that the signature is not an Official ClamAV signature and therefore you need to contact one of the following people when you have a problem:...

  Are these files all malware?

About Sanesecurity.Foxhole.Zip_Js_Js.UNOFFICIAL FOUND and similar you can read at Sanesecurity: Foxhole databases that these are very generic signatures with a high false positive rate, i.e. it will mainly block JS files contained inside ZIP files which is a very common attack vector when transported with mail.

Also the *JsHeur* sound very much like heuristics instead of definite pattern and thus you should expect a high false positive rate too.

Generally any antivirus product tries to find a balance between false positives and false negatives. To catch new variations of malware often heuristics like Javascript inside ZIP or vague defined pattern are used. But these also have a higher chance of matching against innocent data, i.e. a false positive.  On the other hand relying only on signatures which match well known malware but nothing else will cause lots of false negatives, i.e. malware not catched.


How to verify server ownership by public IP (without associated domain)?

You can do this, as Google does with their Web Master Tools. See https://support.google.com/webmasters/answer/35179?hl=en

Basically, Company B can require Company A to upload a small file (e.g. text file) with a GUID in it or with a GUID as a file name. Company B then verifies the availability of this file on every of the acclaimed properties.

However, evil Company C could place that file too, to get the reports also. Company B must make sure, they only send the reports regarding the IP, not for all IP's at once.


Why does oAuth and oAuth 2 have access tokens at all?

maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret.

That's one valid reason, yes. Sending around short-lived access tokens instead of long-lived shared secrets reduces the attack surface.

  Is there any other reason?

OAuth defines several roles. Often a resource doesn't reside on the same server that handles authentication and/or authorization. An access token can be generated by one service and be consumed by another that doesn't actually know anything about who has authorization to what. A resource server might not know which users have access to what resources, but being given a valid access token by an authorization server, it can make a decision about granting access.

Think about access control in a building (or at the border of a country) - the guard at the entrance might not have a list of every person allowed inside and might never have seen you before; but if you show him a valid access card for the restricted area (or passport in the country example), he'll know he's supposed to let you in.

This has a few downsides as well. If access is revoked, but you can retain your access card, chances are you'll still get inside even if you aren't supposed to anymore. This can be countered by putting an expiration date on the access card, and this is why access tokens are usually short-lived, so that even if they're stolen, they can't be used for very long.


Reverse engineering (decompiling) an hackme challenge .exe file in OSX

GNU binutils include the objdump utility which can disassemble executable files into human-readable, or at least programmer-readable, assembly source code. It can do so for any supported target it has been compiled for, regardless of what architecture the tool itself is running on. In particular, it can disassemble a Windows .exe file even when running on MacOS X.

(Installing GNU binutils with support for a lot of binary targets, not only the one the tools are actually running on, entails downloading the source code for GNU binutils, and recompiling it with the appropriate cross-target options. Documentation is included. People who can do anything at all with a disassembled binary ought to be able to do such a task easily.)

Of course, disassembly is only the first step in reverse-engineering. The second step is a lot of hard thinking, which you do in your brain.

Note: I assumed here that the .exe was a Windows binary file, with x86 opcodes. Nowadays, it may also be a .NET assembly, i.e. not x86 opcodes, but CIL. In that case, you will want to use specific disassembler like these ones. It will still work with MacOS X, and still be opensource and free. And you will still need to think a lot.


ARP poison on divided network (every PC in it's own subnet)

ok so first thing is it doesn't sound like your systems are on different subnets as it would usually be understood if your colleague is on 10.169.100.182 and you're on 10.169.100.181 . Assuming a usual subnet mask of 255.255.255.0 , everything starting 10.168.100. is on the same IP subnet.

Next question, when you say you can't "see" each other, what have you tried.  Usually on a standard switched cabled network you won't see unicast traffic that you are not the source or destination for (you should see any broadcast or multicast traffic).  What might be different to your setup at home is that if you're using wireless networking at home the situation will likely be different and there you may be able to see more traffic (depending on the exact config. of the network)

So to establish what filtering is in place you could test with your colleague to see what happens if you try to contact each others systems.

From what you've said you have access to Wireshark.  so if you get that running, then ask your colleague to ping you or port scan you (using something like nmap) you can establish if there's firewalling in the way.

Assuming that there isn't and you can send traffic from one system to another, you can then (with proper authorisation of course) use standard arp poisoning tools to attempt to re-route traffic from your target system via your own and at that point you may be able to use the firefox plugin your teacher refers to (I'm assuming here he means firesheep or similar) see credentials in transit.

This won't work if the connection is protected by SSL encryption (which it should be), then there's more you'd need to do.


How should I protect in-app Android payments when using a separate server?

The possible flaw I see is what you ask in your second question. It is preferable to double check everything server side and treat anything done on a client (even if coming from your own app) as untrusted. In this particular case I don't see an inherent issue, but client-side only checks open the door if a flaw is discovered down the road.

The nonce acts like a salt on the transaction, similar to how *nix systems store passwords. The nonce is used to add entropy to the value that is encrypted with your key, largely eliminating the chance that two transactions are encrypted and result in the same signature, and other similar cryptographic attacks.

I, as a paranoid, would say it is necessary to communicate in HTTPS when you're talking about money changing hands. With cleartext transmission, what's to stop me from intercepting full transaction records at my starbucks and sending them in as my own transactions, among other nasty actions?


Simple tools for searching process memory for MSSQL connection strings

You have demonstrated one of the downsides of using SQL Server Authentication as opposed to Windows Authentication. This is why Microsoft recommends using Windows Authentication unless you have a good reason not to. Here is a description of the pros and cons of each. Notably:

The encrypted SQL Server Authentication login password, must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.

Here is another Microsoft article which talks about how to secure SQL Server connection strings for Entity Framework, but the same rules apply even if you aren't using EF. This statement reiterates why they recommend always using Windows Authentication:

Be aware that logon information and passwords may be visible in a memory dump.
When data source logon and password information is supplied in the connection string, this information is maintained in memory until garbage collection reclaims the resources. This makes it impossible to determine when a password string is no longer in memory. If an application crashes, a memory dump file may contain sensitive security information, and the user running the application and any user with administrative access to the computer can view the memory dump file. Use Windows Authentication for connections to Microsoft SQL Server.

As for whether or not any existing malware applications take advantage of this? Certainly we know that they can exist, and you have proven this yourself. All that is required is for an application to be run with enough permissions to view the memory of another application that stores passwords in memory. The tricky part is it's likely that you would need to know how the memory is laid out in order to take advantage of this. In other words you would probably need to know how the application works first, and then build your memory sniffer around it. Perhaps there are general keywords you could search for, but that would require quite a bit of luck. Kind of like searching the ocean floor for lost ships that might still have some treasures in them; at some point the cost/reward just doesn't make it worth it.
That being said, if you knew that a particular (popular) application had this sort of security flaw in it, you could attempt to design malware that is tailored to that application, and then target that application's users to try to convince them to install your malware on the same machine.


Benefits of REJECT over DROP on a single PC

REJECT is nicer to other people: if the connection is the result of an honest mistake (a configuration error) then whoever tried to initiate a connection receives the standards-approved response that nobody is listening on that port. With DROP, nothing is returned, so whoever is trying to connect will wait until it gets bored.

While REJECT seems better for troubleshooting, a case can be made about how DROP is actually better for tracking bugs. Indeed, imagine a client system that can connect to several servers, until one is found that responds successfully (in a way similar to DNS servers). If the first server in the list is misconfigured, but a REJECT is used, then human users will not notice anything: every attempt will try that server and be promptly responded to with an error packet, and the client system immediately connects to the second server. Such a situation can be in force for a long time, since the human user sees nothing wrong. On the other hand, with a DROP policy, the misconfiguration shows up as a timeout delay for every request, which will induce the human user to investigate.

Indeed, in my daily job, where I must regularly investigate such issues(*), the delay coming from a bad DNS configuration somewhere is often an invaluable tool to pinpoint the problem.

For a personal PC, an additional technical point is asymmetry. Namely a home PC with some Internet access will usually get a lot more download bandwidth than upload (that the 'A' in ADSL). When someone sends to your PC a connection attempt (a TCP SYN), this uses a tiny fraction of your download bandwidth. However, if your PC responds with a rejection (a TCP RST), then this response will use a bit of your upload bandwidth. This opens the possibility of an easy denial-of-service: if you have 10 Mbs download and 1 Mbs upload bandwidth, and you use the "nice" REJECT, then the attacker only needs to send you for about 1 Mbs SYN packets to saturate your network, whether he would need to send ten times as many if you DROP.

In that sense, DROP is probably better than REJECT on a general basis, at least for a home PC. Or, maybe even better, a rate-limiting policy which behaves like REJECT up to some threshold and DROP afterwards (e.g. no more than 10 RST packets sent back per second); I don't know if iptables can be easily configured to do that.

(*) Nominally I am supposed to help design some hairy PKI-related systems, but in practice I spend a lot of time doing this.


Standard practice for distributing server certificate for users

You don't. Typically, the certificate store that contains trusted CA roots is a critically important element of the security in PKI.

It's literally the root of your trust chain. You cannot just have your users add a certificate there blindly because manipulating that store is something that is only done through a secure channel - something that, in your scenario, you have yet to establish.

That is why the best practice is to have you certificate signed by an authority that is already deployed on the client devices - usually a public CA but it could also be a private CA in a corporate network.


Are Cisco switches vulnerable to VLAN hopping?

TLDR;
Prevention:

Don't allow ports to negotiate trunk with any device that asks for it.
Don't put hosts in the native VLAN

I have done demonstrations in the past on Vlan Hopping and this usually comes down to configuration of the devices and the series of switches.

For example, in Cisco's Catalyst family of switches, DTP is set to 'desirable' by default, meaning that it is willing to trunk and all you have to do is tell that port that you want to trunk and it will create that trunk link and negotiate the encapsulation protocol (Usually 802.1Q). I demonstrated this using a tool called Yersinia.

Some families of Cisco devices don't even use DTP at all and use a different process and/or protocol for negotiation of a trunk link.

Another variable that has to come together for this attack to happen is the use of the Native VLAN.

An easy way to prevent such attack is to not place any hosts in the Native VLAN and/or set DTP mode to nonegotiate.

Overall, you'll have to see if the IE series uses DTP. If it doesn't but uses something similar then make sure your ports will not auto trunk with any device that asks for it. This would essentially prevent a rogue device from trunking and sending double encapsulated packets which also needs to make use of the Native VLAN.

To say your devices are vulnerable or not is hard without seeing the configuration but the above methods with help prevent the attack from succeeding.


What is the point of encrypting my files (on a server); if I can decrypt them why can't a hacker do that too?

I don't know what decrypt() does, but you probably mean your OS-specific cryptography API. On Windows, this is protected with your account password. If the data gets downloaded or stolen, it will be much harder to read, even knowing you password. When your server is rooted, all bets are off, this just obfuscates it.


Do these non-zero durations in btmp indicate someone is logging in?

btmp is failed login attempts. Those user accounts do not have to exist to appear in that log. If you start to see weird entries in wtmp or utmp, then you should start to worry.


Evaluating hosting providers for CC development environment

The "real" answer depends on where you intend to get your CC evaluations performed.  There has been a recent upheaval in the CC evaluations world with US and Canada (and Australia) in one camp, and most of Europe in another camp.  (I see from your uid that you may be in France.)  Specific schemes may have specific requirements.  You will need to contract with an evaluation facility anyway, so you might as well get that ball rolling.

The reason why the location is important is that the US/CAN market is moving to assurances at EAL2 and lower (and then they are going to get rid of assurance levels altogether).  At EAL2, the only two things in scope for "infrastructure" purposes are the configuration management system and secure delivery/supply chain.

The requirements for EAL2 are pretty modest and basically say that you NEED to have a CM system and the product and documentation has to be controlled within the CM system.  However, no demands are made on specific functionality other than to show that it is controlled (it doesn't even need to be automated for EAL2).

Now, in France, if I've correctly translated, the CC scheme (ANSSI: Agence Nationale de la Sécurité des Systèmes d'Information) appears to be continuing down the path of medium-to-high assurance certifications (eg. EAL4 and up).  At EAL4, there are significant security requirements levied on the development environment, tools, and the CM system.

The key, however, is that the CC is not prescriptive: it doesn't tell you what security functions you must have, only what the end result is (eg. it must protect the confidentiality and integrity of the product).  One of the key things to remember is that where the developer's measures are deemed less than adequate by the evaluator, a clear justification must be provided based on the potential for an exploitable vulnerability.

I suggest you first look at what level of assurance you are looking to achieve (usually a marketing decision more than anything else). Use this decision to determine which assurance components are going to be included (dependent on the scheme, of course): this grid is found on page 231 (table 24) in Appendix E of CC Part 3.  (For your situation, you are only interested in the ALC (Lifecycle) assurance class.)  Then, look up these assurance components in the body of the same document.  You are looking for the "Developer action elements" and "Content and presentation elements" such as ALC_CMC.2.1D and ALC_CMC.2.1C.  It helps to know what an evaluator will be looking for, so I urge you to read the Common Evaluation Methodology (CEM) for the same assurance components. Based on what you find, you'll be in a better position to formulate the right set of questions.  Many of these questions will be directed to your internal integration team, some will be questions about product features.  As an example, at EAL4, you need to have automated access control and build integration (eg. ALC_CMC.4.4C and ALC_CMC.4.5C) in your CM system.  However, you will also need an extensive "CM plan" describing how your development environment uses the CM system (ALC_CMC.4.6C).  This will be developed internally.

I would find it highly unlikely that you'll find a list of products that are "CC Ready(tm)!".  The reason is because CC is more concerned about the end result rather than how you get there.  Therefore, a spreadsheet might be an acceptable form of configuration management system for EAL2 as long as there are policies and procedures in place to ensure it is enforced.  This would not fly at EAL4.  Conversely, just because you use the Bells and Whistles Source Control Management System(tm) doesn't mean you will pass at EAL2, either because you might not track all of the necessary items.


Is it possible or common for a website (without ads) to only sometimes do a malicious redirect?

It is not uncommon for infected sites to only infect some visitors, detect repeated visits, exclude specific IP ranges or user agents from infection etc. This is done to not be detected by researchers and thus stay off blacklists and this way infect more users. See for example WordPress Redirect Hack via Test0.com/Default7.com where they describe that redirects within this specific infection happen only in 15% of all cases.


A DDoS attack is near impossible to prevent or stop at a local level.

I strongly encourage the use of a service like CloudFlare which is aimed at mitigating DDoS attacks. Another alternative is coordinating with your ISP to drop DDoS like traffic.

The recent Spamhaus DDoS attack demonstrates how effective a service like CloudFlare can be in mitigating large scale DDoS attacks. While the amount of bandwidth being thrown at the target is enough to almost overwhelm even individual Internet Exchange Points, the target site remained accessible throughout the attack.

Edit: Reading your question again, it appears that your login page only needs to be accessible to a few administrators. In that case, requiring a VPN to access the login page might do the trick. My previous point still stands though, if a determined enough attacker is willing to expand resources on your site, you can only mitigate attacks through a service like CloudFlare.


WEP cracking - Why does many IVs allow to actually get the cipher key

I actually got my answer.
Once you get M1 XOR M2, you can derivate the actual keystream. Moreover, as the IV is sent in clear with every packet, you can now associate this IV with the KeyStream you found.

Using this technique on enough packet, you can construct a IV - Keystream dictionary.After a certain number of packets captured (not that many considering the "Birthday paradox"), you'll be able to construct a pretty exchaustive KeyStream dictionary which then allow to decrypt incoming messages.

This is how it would work:

You intercept a packet
You look at the IV coming with this packet in clear
You check in your dictionary to see if you have the corresponding Keystream for this IV
If yes, you use the keystream to decrypt the message. If not, you keep the IV and wait for another encrypted packet with the same IV, which would allow to get Keystream for this IV (by XORing the two packets) and add it to your dictionary


OpenBSD is implementing KARL. How does this improve security?

From what I understand, this is a step beyond KASLR. For memory location inferences at a finer granularity than what KASLR protects.

With KASLR, you make it harder for ROP gadgets to overwrite (e.g., heap spray) areas of memory that will eventually yield control to injected/known code. However, this being an arms race, counter moves such as JIT spray have evolved.

  An info leak of a pointer will not disclose other pointers or
  objects.

As with ASLR which randomizes and hence makes it harder to "find" userland function entry points to tamper, and KASLR doing the same thing - both are still vulnerable - if an attacker can

study the way the kernel components are linked and loaded into memory relative to each other
then "find one point of reference" (in this case, by an info leak of a pointer") and then
apply the earlier knowledge to infer the locations of other sensitive objects / functions that could be targeted by gadgets.

  How does this improve security?

Apparently, KARL makes this inference much harder because you'll need to study (1) afresh after every reboot. This raises the cost of exploitation significantly (except in a situation where attacker doesn't even need to reboot even as they mess with kernel in a largely hit and miss technique) - and thus makes the OS more secure.

  What type of attacks would be mitigated by this new feature?

Gadgets that depend on inferring kernel object locations based on a separately "knowledge of" a point of reference.

  How is this different from Kernel Address Space Layout Randomization?

This is an additional defense on top of KASLR. To defend against use of gadgets that work at a finer granularity that what KASLR defends against.


The general Amazon API model involves the following steps

Build your API request with all the elements (within a program structure like an array)
Order and format the request elements
Calculate the HMAC of the formatted request
Send the full request to Amazon, with the HMAC

Amazon then takes the request, generates its own HMAC, and if it matches, it validates the request (provided your authentication tokens also match).

There's no way to ensure your security if you put your keys within an app. You would have to force any compiled client to contact your server and do the API request there.


How practical are proof-carrying codes to guarantee security of a program?

Ok, so trust is relocated from the component to the proof checker.  On what basis can the proof checker's certificate process be trusted?
The proof checker's certification process can be trusted because:

the proof checker defines the safety policy;
the proof checker employs its axioms to validate the safety predicate, and so knows whether the safety predicate meets the conditions of the safety policy, or not;
The proof checker establishes the VC-generation rules, proof rules, and preconditions, (essentially the 'calling convention') that defines how the code consumer invokes the binaries.

Seems all good right?  Before any of this happens though, the code consumer defines and publicizes its safety policy.

Do safety policies remains static?
Are safety policies, at any point in time, sufficient with their VC-generation rules, proof rules, and preconditions to certify that safety predicates truly establishes compliant non-malicious code?
Can code producers really certify a safety predicate using first-order logic in polynomial time?

To the first point, if the safety policy is found to be too simplistic, or ineffective lacking the proper axioms, it will change, which means it must be rewritten and republished, which means the code producer must redevelop a safety predicate and safety proof for re-certification.

What code-producer (hoping to have their code re-used in different environments) is going to constantly be recreating safety predicates and redeveloping safety proofs every time someone's safety policy changes, for every possible scenario?  The issue of trust is a constraint on the code consumer, not the code producer who may not care if their binaries are trusted.

To the second point,
To formulate safety policy, code consumers must make assumptions about what constitutes sufficient conditions to certify a safety predicate.  Simply because a safety predicate receives certification, does not mean it is truly safe.  Rather, it only means that it has meet the minimal necessary conditions imposed by the code consumers; so some minimal threshold for sufficiency which may not be enough to ensure real safety.

If a code consumer constructs and publishes an ineffective safety policy, the certification process is not providing a sufficient control against malicious code execution.  In fact, this model has the code producer abrogating their responsibility for writing trustworthy code, in favour of writing code that merely passes the minimal conditions for certification (i.e. one that produces a minimally acceptable safety predicate).

Finally, to the third point,
The author notes "In order to create a safety proof, the code producer must prove a predicate in first-order logic. In general, this problem is undecidable."

If creating a safety proof requires proving a predicate in first-order logic which is 'in general' undecidable this implies the code producer cannot in general create a safety proof - so what good is certification in the first place?  Isn't it all merely academic?
There are other problems the authors reference noting in the Introduction that "... there are many difficult problems that remain to be solved."  Truly!
ANSWER:

You ask Is there any reason PCC is not more widely used?
It sounds like there's very little incentive on the part of code producers to be more widely using this model, given the apparently impossible battle they face in creating a safety proof for their predicate and in having their safety predicate meet conditions of some particular certification process.


I think it largely depends on what else you were doing at the time you created the capture. For example, if you were browsing the web, then obviously people would be able to see what websites you were visiting and the content of any unencrypted pages. If you were logging in to something that does not use encryption (for example, telnet, FTP, or a non HTTPS website) then your login information could be in the wireshark capture. Granted, this is fairly unlikely as encryption is used for nearly all logins these days.

Other than that, the wireshark capture will contain broadcast packets from other devices on the network, in addition to MAC addresses. These are fairly unlikely to contain any sensitive information; some people may consider MAC addresses to be sensitive, since they are unique to each device, but unlike public IP addresses they cannot be easily linked to a location or specific person. All it really reveals is the manufacturer of the computer/network card.


A password manager a single point of failure. Then why is it so often recommended nowadays?

And on top of that, you'd need dozens of these long random passwords
  and so you need a password manager like lastpass or keepass.

  I just find it a little scary that I'll know none of my own passwords
  (except the one to the password manager).

Well, it's a trade-off.  In exchange for getting strong complex passwords, you give up your knowledge of each password, and you introduce the danger that an attacker who compromises your password manager gains access to all your passwords.

In real world terms, the alternative - humans either choosing weak passwords which they can remember, or the same password for every system, or one weak password that they use for every system - is a worse case scenario.

You don't have to love the right solution.  Sometimes the right solution is just the lesser of two evils.  (And, frankly, a good password manager has relatively little evil.)

  Isn't there any other solution? Or perhaps a way to make this a little
  less daunting.

Yes - the other solution is the use of OTP with federation.  Something like Google Authenticator, where you have a software token which provides rotating passwords, and where the "secret key" used to validate those passwords is owned by one entity who allows multiple systems to leverage it for authentication without giving each system access to that secret key*.

This third option also has upsides and downsides.  If not knowing your actual password bothers you, then being reliant on a device to provide you with passwords that are only good for 60 seconds may bother you more.  The security of the system is better than the other two for a number of use cases.  However, the applicability (e.g., systems you want to use may or may not support it) is worse.

*As opposed to, say, RSA SecurID tokens, where the seed file which is the "secret key" needs to be installed on each RSA installation, so either your seed is shared among multiple entities or you have multiple tokens.


What are attacks against hash collision resistance property?

Hash collision in a signature is for example a problem in document signing if the attacker can provide both signed documents. Just imagine a case where somebody orders you to do some work and the conditions are inside a signed document. Once you are ready they present you with a different version of the document which contains a lower pay for you but which still matches the signature.


How does a key file increase the security of a password manager?

Authentication methods can often be divided into one of three areas: something the user knows, something the user has and something the user is.

Passwords are something the user knows. The user memorizes it in his head and can "retrieve" it from memory as and when it is needed.

The key file acts as something the user has. Ideally, this key file needs to be stored in a secure location.

Personally, I have copies of my password database everywhere. My desktop has a copy, my laptop has a copy, my phone has a copy, my tablet has a copy. I store my password database on Dropbox which allows me to keep it in sync between my various devices.

However, I do not store my key file together with my password database. My phone and tablet has a copy of it, because there is no way I can insert a USB drive into those devices, but my desktop and laptop does not. I store my key file on a USB drive which I keep on my person at all times. This makes it slightly more difficult for an attacker to obtain my key file.

Using a key file in addition to a master password is helpful, as it raises the difficulty of successfully compromising your password database.


Flash has been a high-value target for exploit developers for years, particularly because of its near-ubiquitous installation base and the fact that (historically) it will generally run automatically whenever a page with Flash content is loaded. This makes it very easy for a large number of systems to be targeted and compromised with a single exploit.

As it turns out, Flash apparently has a lot of flaws for those developers to discover as well. This has resulted in dozens upon dozens of Flash-related CVE entries every year, with many of them starting off as zero-day exploits. Flash Player is currently #16 on CVE Details' Top 50 most vulnerable products list, with a total of 510 vulnerabilities discovered since 2005. The last year in which there were less than 50 vulnerabilities discovered for Flash Player was 2009, and there's already been 132 discovered this year!

Flash Player Vulnerability Statistics

The vulnerabilities that have been cropping up aren't trivial things, either. Nearly 84% of Flash Player vulnerabilities discovered to date are usable for code execution, and about 80% of all Flash Player vulnerabilities are rated with a CVSS score of 9 or higher!

So, what can happen if you keep Flash enabled while indiscriminately browsing the web? Very bad things.

What should you do if you use some sites that still require flash? Find a different provider for those services, if possible, who doesn't require Flash for their site. All major browser vendors are abandoning plugins in general, so it's just a matter of time before you'll have to start using some obscure specialty (and/or outdated, and therefore even more vulnerable) browsers if you need Flash.

If you absolutely have no other choice but to use Flash, Chrome currently has a built-in Flash Player that gets automatically updated along with the browser. IE 10 and later, on Windows 8 and later, also has built-in Flash but Chrome is preferred for its (generally) better security and background updates.

Another thing you could try is to just disable Flash and see what happens. Many sites will say they require things like Flash and JavaScript, while their most critical functions actually do not depend upon them. Often times, the Flash/JavaScript used on those sites just enables some features that offer added convenience or non-critical functionality. In a number of other cases, you'll find that the only thing that breaks with Flash/JavaScript disabled is the ads!


The discussion you are linking actually says that you should not hash your token, you must only ensure that it is long and random enough, quoting Tom Leek:

  Don't compromise, use a good PRNG. Don't try to make something
  yourself by throwing in hash function and the like; only sorrow lies
  at the end of this path.

However, as per your specific concern, using a poor predictable token could allow an attacker to enable accounts, as you said, but more importantly it will be allow him to do so without having access to the associated email address, thus bypassing the role of the email verification system.

For instance an attacker can create an account on your website using a fake email address. This account could then be used in social engineering attacks (the attacker could act as if he was an employee from some large company, another member colleague, etc.).


I do not think that would help much. Visiting pages randomly (and thus triggering all their ads and trackers) is totally random. Your real browsing, however is not random and follows a pattern - stuff you're interested in, at what times do you open the websites, etc. It would still be easy to tell the signal apart from the noise.

This could work against a small attacker like a site hosting their own ads or a tiny ad network without too much machine nor human time to analyze the data, but given how much money this crappy advertising industry has, the major players like Google and Facebook most likely solved this problem a long time ago.


How Can I remove the metadatas of a .py file?

Python files (.py) are just text files with a different extension that allows the operating system to easily recognise them. The 'metadata' seen in the Properties window is simply some information that is associated with every file, like the creation date.

The tool you are trying to use is for removing EXIF data from photo's. EXIF data is normally only included in image files, and your tool will not be able to remove it if it doesn't exist.

If you want to remove the information from the properties window before you send the file to others, there is no need to do so. When you send the file to other people normally (e.g. via e-mail) only the contents of the file (and sometimes the filename) is sent, no other metadata.


I think the biggest red flag to me is that he talks about the secure enclave. That model didn't even have one. I think that's enough to tell me he doesn't know what he's talking about.

  The recovered iPhone is a model 5C. The iPhone 5C lacks TouchID and, therefore, lacks a Secure Enclave. The Secure Enclave is not a concern. Nearly all of the passcode protections are implemented in software by the iOS operating system and are replaceable by a single firmware update.

Source

If I could guess what he was getting to, it would be that he's on about getting an unofficial patched/modified iOS to boot to the lock screen and then allow it to allow numerous unlock attempts without wiping which is what was requested but limited by the iOS signing protection, when he's talking about just getting it to boot and fingerprints he is perhaps talking about bypassing the iOS signing protection that means the device will only boot official iOS code that it likes and matches the trusted fingerprint. From there the cracking can begin.

The fact he references a secure enclave that doesn't exist however to me makes me dubious of his further statements.

The best write-up I have found for this is at http://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/ most other sites appear to be getting this horrificly wrong.


Is a single pass enough when disposing of a HDD?

According to the articles linked below 1-2 wipes will be enough.

  For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, “A good scrubbing with random data will do about as well as can be expected“. This was true in 1996, and is still true now. “

Even if some data is left unerased or recoverable after the wipe, it is highly unlikely that someone will be able to find it.

  “…with modern high-density drives, even if you’ve got 10KB of sensitive data on a drive and can’t erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 200GB of other erased traces are close to zero.”

Articles:

HTG Explains: Why You Only Have to Wipe a Disk Once to Erase It
How Many Overwriting Rounds Are Required to Erase a Hard Disk?


About SHA1 in default Disk Encryption in Linux

Let me just use an answer to explain differences between key-stretching and hashing, even though this isn't an answer to your question.

I'm not going to use a real-world example of collisions, because I don't know what they are, so my hash examples will be purely random.

Imagine your password is pass123, let sha1Result = sha1('pass123').

A collision is when bksdajfdjfaskf can also be used, where sha1Result also = sha1('bksdajfdjfaskf').

A KDF is a feedback loop, where sha1Result2 = sha1(sha1Result) and sha1Result3 = sha1(sha1Result2) and so on n number of times.

The below example KDF() function will be KDF(password, hash-algorithm, iteration-count)

Let kdfResult = KDF('pass123', SHA1, 100,000).

Let kdfResult also = sha1('jadfjlkdfjasldfjskdf') because we have a collision, sort-of, but not really.

Because in order for you to log into my system, you must pass through my KDF(), just having a sha1() collision of my KDF() does not help you, because I do not sha1() your supplied cleartext in order to authenticate you, I KDF() your supplied cleartext, and KDF('jadfjlkdfjasldfjskdf', SHA1, 100,000) does not match KDF('pass123', SHA1, 100,000).

This is a different use-case for a KDF than for HDD encryption. For HDD encryption, the KDF is not used to authenticate, but its used as a key for the encryption of the data.

However, that might be what you should reform your question around. Are the SHA1 collision vulnerabilities still a vulnerability when iterated 103,696 times?


What kind of redirect of websites is this?

They are using HTTP 301 (Moved Permanently) and HTTP 302 (Found) like anyone else. When I type in the url bar http://ign.com it redirects me with HTTP 301 to http://www.ign.com/. Then it redirects me with HTTP 302 to http://[country subdomain].ign.com/. Finally it redirects me to HTTPS with HTTP 301 to https://[country subdomain].ign.com/ with HTTP status code 200.

To prevent the unnecessary redirects, you can install a proxy and strip out the redirects.


Is a "logged_in" session flag secure enough?

if ($_SESSION['logged_in'])

This can be secure. There is no straightforward way for an attacker to modify $_SESSION or the variables within. The only way it becomes true is when your web application sets it to true.


Google Chrome folder protection during HDD forensics

No, it is all unencrypted. You can copy the folder located at %LOCALAPPDATA%\Google\Chrome\User Data (or similar folder on other OS) and place it in the same location on another user/computer to have full access to everything in the browser's profile. This applies for most other browsers as well.
You should use disk encryption if you are worried about data being read of your computer. Alternatively you can configure Chrome to not store any data in the browser or clear it every time you exit the browser.


Terry Chia, we meet again xD. Simple put, although technologies to track hackers are present, there are a number of constraints on governments that prevent them from doing so. That said, a private individual working as a blackhat will probably have better chances to track a particular hacker.

To begin with, the main reason law enforcement agencies arrest hackers in the first place is their connection to their (generally some crappy free) VPN breaks down without their realization. The reason IP Spoofing is so devastating is if a US individual spoofs a Russian and then Chinese IP, it is almost certain that the two governments would never help US law enforcement. So you ask how it can be done?

To track such a hacker a number of precautions would have to be applied on the server, JavaScript and PHP like languages can provide useful information such as the clients browser, operating system, etc which is generally not spoofed. Additionally, web application attacks will not work because I doubt the hacker will stay on the same IP for long.

For example, Google has been known to be able to track users even under spoofed IPs and disabled geo location instantly. They do this, by capturing all wifi points in range every time you connect to them, by matching this to their existing database of wifi points they could easily locate you. The technique essential works by invading user privacy. If the "law enforcement" could access such a database, they could use it against you. Additionally if they can somehow sniff such traffic they could obtain the same info.

Here's a video demonstration that: http://www.youtube.com/watch?v=McF50tjuFEs

Ultimately, it's not viable for law enforcement to accurately track or arrest any individual, because laws in most country believe that a person is not guilty unless convicted. What I mean is that, even if they get your "true IP" and come to your house, hackers have been known to have security measures to erase disks several times over beyond capabilities of cyber forensics or use Deep Freeze/TrueCrypt to hide and lock that data with multiple unbreakable layers of encryption.
If you do it right, there's no "evidence" on your PC. In fact, people can got away in many cases because they claimed their computer was used as a zombie or their wifi was hacked. In many cases it is true.


Multi Factor and order of authentication

The reason to prompt for the password factor first instead of the second factor tends to be either to prevent harassment of the user or to reduce costs associated with usage of the 2FA service.

For example, with Twitter they send a push notification to the user's device for login verification.  If it didn't require the user's password first to authenticate them then attackers could spam their device with login verification requests all day long.  Or if they used the SMS option the same thing would happen with texts to their phone, plus I believe Twitter has to pay SMS gateway providers for each text they send.  This would disincentivize users to enable 2FA.

There are 2FA factors which can be implemented so they aren't intrusive to users or expensive to providers, like TOTP/HOTP.  If a system prompted for the one-time password token along with the username they could verify this first before asking for the user's password.  From what I've heard this is actually done with Norwegian BankID.  Hackers can still annoy the authenticating site by flooding it with username/OTP guesses, but the site can also deal with these problems in a similar way to password guessing attacks.

Authentication based on WebAuthn would also work well with a stronger factor first design, or without a second factor password at all.

I assume there are probably some usability issues with switching the order.  You would have some people typing their password into the OTP field if you start prompting for that before their password.  That could lead to some account lockout issues.  However, you could probably reduce this to a manageable level with training and effective UI design.

I also agree with you that there are just traditional app design issues influencing some of these decisions.  You would likely need to ask a user for their username alone and then determine what next step to prompt them for (password or other factor) based on a lookup of their 2FA enrollment status.  Google does this already, but I haven't seen this design pattern implemented a lot by other sites yet.  With time we may see others adopt this same approach.

Most sites are primarily concerned with preventing account intrusions against their users and not as much about whether an attacker happens to figure out a user's password can work elsewhere.  After all, the attacker could still actually try their same password guesses against the user on all those other sites.  Beyond combating this with normal password guessing prevention controls, I don't imagine many administrators spend time worrying about that possibility.


Does Java applets reveal the real IP address, even when using proxy or vpn?

Yes.  Java applets can access the original client IP address using java.net.InetAddress.getLocalHost().getHostAddress() and then send it anywhere.

See also Are there any addons that disable only some functionality of scripts? and the Tor documentation (e.g., this page) for more discussion of how various web technologies could reveal your original client IP address.

Java applets can also bypass your web proxy and send packets directly back to the domain where the applet was loaded from.  This then reveals your client's IP address (not the proxy's IP address) to the site hosting the Java applet.  A Flash applet can also do something similar.

Also, many proxies will reveal your original client IP address, without the need for Java applets or anything fancy, through the X-Forwarded-For header.

See also Metasploit's Decloaking Engine for more discussion of ways to track you and recover your original (real) IP address.

And finally, you might be interested in
How much can I trust Tor?,
Different strategies for online anonymity and their +/-s?,
Whats the best way to make my internet traffic anonymous?,
Does using an http proxy completely hide my real IP address?,
How to browse the Internet safely?,
How anonymous is my setup?.


Why do we receive contact form spam with random characters?

The thing I could think of is password bruteforcing, in that the bot doesn't notice that it is on a contact form and instead just tries to log in with a mail address and random password. However, the chances of this working are astronomically low, given the general odds and the low number of attempts (two)

Your idea isn't so bad. It may be 2 attempts a day to bypass the common 3 attempt lockout policies.

  Note: I have changed the mail address. It looked like a legitimate mail address of a larger company, e.g. First.LastName@companyname.com. That is always the case.

Further proves your point. Try running the address through haveibeenpwned.com and see if it occurred in a breach. If so, you may deal with a case of credential stuffing.


How do I secure my REST api that is being accessed by only one application?

You must use SSL. If you don't - no matter what other security scheme you select - it will be prone to sniffing and hence the bypass of your security mechanism.
For example an attacker by utilizing DNS poisoning will make your AppA think it is talking to AppB and send the token to the attacker... from there your whole security mechanism is broken.

SSL will provide you with both authentication of your application to the API and confidentiality + tamper resistance of your data between the app and the API

In SSL you can configure two way authentication, which means that beyond AppA being sure it is talking to AppB, also AppB can be sure it is talking to AppA. This is done by configuring SSL to request also client certificate in the SSL handshake.
That is your best option. I would not risk trying any self made security protocol instead.


Have you checked if the ARP table is updated on the Asus router? It could be that the router ignores the arp requests.

What router do you have? Have you flashed it with some custom firmware?

You can also check the arp table on your Macbook Air using the command: arp -a  # to see if it has been updated.


Am I exposing too much via port range forward on home security system

You asked if it was too many ports. That's kind of the wrong question. One port can be too many.

If you want the services that the device provides, and you are willing to accept the risks of outsiders gaining access to the device as a result, then one port or 10, it doesn't matter.

I'd still want to limit your risk by placing this device in a guest network or a separate VLAN, in case the device is taken over to become a pivot point for an attacker.


Is it possible to check if a USB's firmware is unmodified when plugged in?

Let's say I have some USB stick that I know and trust. I can examine
  the firmware and generate a checksum for it.

  Can I use this checksum to ensure that when the USB is next plugged in
  the firmware was not modified? Would it be possible to do this before
  and firmware ran?

I don't see why not. Since you already have some method to examine the firmware (apparently), why not just examine the firmware again when it is next plugged in, take the checksum, and compare to the known good checksum...

This seems obvious, so maybe that this is not what you are asking about. However, if this is not what you are asking then your question is not clear to me...


Is it safe to store the reset password token in PHP session

Is it safe to store the randomly generated token in the PHP Session or should I use database?

It can be if done properly. How is access controlled to the files that store the session information? This is especially a concern on a shared system.

There are drawbacks to this approach though. Sessions expire and email can be slow. If the user doesn't get the email immediately, they may close the browser, in which case the session id stored in the browser would be cleared. Then when they get the email and type in the secret, you can't validate the request.


Yes they can. Of course it depends on conditions like:

How are the ethernet switches configured
Is there any logging enabled

Also on non-technical conditions like what happens after they freak out:

You don't say a thing they report it to IT and an investigation starts (and they might look at everyone's browsing history, looking for "arp spoofing")
You tell them it was a prank and they report it to HR

In the end the main question you should ask yourself is: would this violate company policies, and if so is it a firing offense? followed shortly by is it worth?

How about setting up a private network on your home computer and playing in a safe environment.


Does a professional website know that person A switches the Chrome "user" and logged into its website with another email address?

how is two people using two accounts on the same device different from one user using two accounts in the same device from the point of view of example.com?

Nothing. example.com may know that there is two accounts connected to itself on the same device and even know that accounts are open in the same browser, but can only guess whether it is the same person or not. Your question is logically out of context, I can open another account on the same device and give it to my brother for him to use. How on earth server will know it is me or not?


What methods are available for securing SSH?

Disable Root Login - Most automated attacks will concentrate on the root account so disallowing logins from that account is a good place to start.
Only Allow Certain Groups/Users - Limit what users and groups can SSH to the system.
Limit by IP or IP Range - One of the most effective ways of securing your system against SSH attacks.
Use Key Based Authentication - As described by Olivier
Use fail2ban - fail2ban will monitor attempted SSH logins and after a determined number of failed attempts it will block the attackers IP address for a set time period. This can be a very effective method for slowing down attackers.


You might want to investigate Password Managers such as Lastpass.  (This is just one example; a search for "Password Manager" will bring up many others.)  In addition to storing userid/password credentials for specific URLs, these systems have the ability to store files securely, so you could save all this information in a secure note, and then share internally to the people who require this information.


How to change the browser canvas html hash for fingerprinting?

I think you've misunderstood what the canvas hash is.  The "canvas" is a JS component that allows the browser to draw graphics.

The hash input is only a single thing, the binary data that makes up the image drawn by your graphics card.

Obviously, a number of things go into the generation of that image.  There are multiple JS engines used by different browsers, which will affect the generation as well as the version of the engine (and of the code running on the engine).  Additionally your graphics drivers, the GPU and/or CPU will all have an affect.

However, none of that (besides switching browsers) is easy to change on a regular basis.

The good news is that their are a limited amount of combinations of these things.  I'd imagine something like the newest Chrome, on Windows with an Intel CPU and integrated GPU is likely to be the most common combination.

As was said in your previous question, that is only a single element of the fingerprint built up to uniquely identify you.  This website gives you a good idea of how unique (or not) you are.


The following steps will help you diagnose the SSL errors you receive in Chrome.

Firstly, after going to the site which generates the error, press the F12 key to bring up the Chrome DevTools.  Select the Security tab item to see more about the certificate and the SSL connection:

If there's a problem, it will be highlighted in Red.  In this case, the certificate is signed with the weak, deprecated SHA-1 algorithm:

If the error complains about the certificate in some way, you can click on View Certificate to get more information.  For  example, it's good to check the Certification Path to make sure the certificate appears to be legitimate:

If you'd like to learn what effect the different "bad" configurations will have on Chrome, you can explore the sites from Bad SSL:


Since you can see the DNS cache has the poison in it, it sounds like you're doing the poisoning successfully.  My best guess:

The DNS server the machine running nslookup is configured to use isn't the one that's being poisoned.  (In other words, you're poisoning the bind server you set up, but nslookup is causing lookups to, say, your ISP's DNS servers, or Google's or OpenDNS'.)


How sensitive are acoustic side-channels to compression with a narrowband codec?

According to Wikipedia:

"... G.711 passes audio signals in the range of 300–3400 Hz and
samples them at the rate of 8,000"

Nyquist criteria limits the top frequency to be less than half the sample rate, or less than 4 KHz in this case. Further G.711 filtering apparently cuts this down to 3.4 KHz top.
A quick impromptu experiment
Laying the microphone of a USB headset next to my very clicky old Dell keyboard and recording the sound gives me an amplitude time space recording of:

Running a Fourier transform to frequency space yields:

It looks to me like all of the subtle key impulse differentiation lies in the 5-20 KHz region, which by definition cannot be passed by G.711
This was a quick and dirty experiment, take it for what it's worth.


Should users need to complete a CAPTCHA upon changing their password in their account settings?

As mentioned by AndrolGenhald, it could be to provent automated takeover of accounts with compromised credentials. Even without the last.fm breach, I imagine that whenever credentials are breached for any site, robots try out the credentials on a bunch of different websites, possibly including last.fm (this is why it's bad to reuse credentials).

While last.fm, like other sites, could put a captcha on their login page, it would be much more inconvient since users typically log in much more often than they reset their passwords.

In the end, they are blocking robots from doing the thing that would be the easiest to automatically do to hacked accounts: reset the password


DISCLAIMER: I'm neither JtR user nor Perl programmer. This answer that follows is a product of years of training in Google-Fu alone, combining a few answers from newsgroups and some JtR documentation.

John the Ripper (JtR) rules do not support multiple input words.

The only exception is with the single crack mode where operators 1, 2, and + control if other commands are applied to the first, the second, or to both words respectively, when testing against a word pair, such as first and last name.

Alternatively, you could redirect the output of an external script (handling word combinations) either into a john --stdin or into a file (and use that as a wordlist with JtR). Doing so will obviously slow down the process as the number of possible combinations increase exponentially with the number of input arguments, thus is probably only worth trying on really short word lists.

Here are some Perl scripts that you could adopt to suit your needs (or use as is?):

Two word combinations:

#!/usr/bin/perl

while (<>) {
    chop;
    $w[$#w + 1] = $_;
}

foreach $a (@w) {
    foreach $b (@w) {
        print "$a$b\n";
        print "$a $b\n";
    }
}

Three word combinations:

#!/usr/bin/perl

while (<>) {
    chop;
    $w[$#w + 1] = $_;
}

foreach $a (@w) {
    foreach $b (@w) {
        $ab = "$a$b";
        $a_b = "$a $b";
        foreach $c (@w) {
            print "$ab$c\n";
            print "$a_b $c\n";
        }
    }
}

Four word combinations:

#!/usr/bin/perl

while (<>) {
    chop;
    $w[$#w + 1] = $_;
}

foreach $a (@w) {
    foreach $b (@w) {
        $ab = "$a$b";
        $a_b = "$a $b";
        foreach $c (@w) {
            $abc = "$ab$c";
            $a_b_c = "$a_b $c";
            foreach $d (@w) {
                print "$abc$d\n";
                print "$a_b_c $d\n";
            }
        }
    }
}


OAuth 2.0: What is the advantage of authorization_code grant flow over Implicit grant flow?

Sure, you can do that, and in fact it's a supported flow as you mentioned. However, the point of the code is to prevent the client itself from having access to the token. This prevents stealing or leaking of the token because it's confined to the internals of the web app itself, instead of shared around with whoever needs to use the service.

Remember that the flows apply to different scenarios.

Implicit flows are used when you need access to the token, but don't/can't trust the client such as an app running locally on a user's machine -- a malicious user could easily impersonate the client.

Code flows are used when you can trust and verify the client because, for example, it's hosted on a remote machine you don't have access to.


Using a laptop effectively prevents this.

You could glue the keyboard into the USB socket. Not ideal, but hey :-)

Another is to use a Bluetooth keyboard, with integrated Bluetooth on the computer.

But these are all kludges really; in general I agree with the other comments that if an attacker has physical access, most bets are off.

This is quite a good example of where it is important to understand your potential attacker. The Bluetooth keyboard approach will reliably stop a colleague casually installing such a device. It won't stop the CIA/NSA - but you probably don't mind that. A lot of the other answers assume your likely attackers are highly skilled and resourced. If you're that much of a target, I'd guess you wouldn't be asking this on the internet :-)


Best practices when classifying log messages severity in an SIEM

This will entirely depend on what your goal is. Generally you need to classify the severity based on the threat of business continuity. First of all categorize per type and subcategorize:

Security Events => external, internal
Availability => hardware ( disk arrays, batteries going bad, chassis open...), software (Is the http service still available, what is the response time, what are our machines using in resources, ...)

Then for each subcategory you decide the criticality of each event yourself, keeping in mind: "What threat does this event pose for our business continuity". You could differentiate with:

Low (Warning, but no direct impact if problem increases, a failing)
Medium (Warning, but has impact if problem increases)
High (Danger, system is close to becoming unavailable)
Critical(System is down or business critical systems are close to failing)

For security events this could be the same. For instance, an external port scan might be a medium risk, you need a warning, but it's probably just internet noise, whereas a port scan coming from the internal network is a lot more worrying.


What benefits do Hardware Security Modules provide when keys are not stored inside them?

In many HSM, there is very little capacity for safe storage (say, a few kilobytes). Therefore, what the HSM really stores in its entrails is some master key K (symmetric). The key pairs that applications use are stored externally, but encrypted with K; they get decrypted and used only within the HSM. In such a setup, keys are both "logically" inside the HSM, and "physically" stored outside. This may be what happens in the system you are are interested in.

What good a HSM does for security is an interesting question. Basically, the HSM ensures that if your keys are stolen, you will know it, because the only way to steal the keys is to purloin the whole HSM, at which point you no longer have it. This contrasts with software keys that can be copied without leaving any trace of the theft.

If a HSM is used with externally stored keys, without encryption with some master key as described above, then the HSM really is a simple accelerator, used for performance reasons, not for improved security. This used to be popular a dozen years ago, but lost much of its relevance with the increasing performance offered by basic PC. Most HSM have rather "fixed" designs because any change to a HSM invalidates its EAL 4+ / FIPS 140-2 certification, so a lot of HSM designs currently on the market use ASIC designed a decade ago, with performance that used to be really good, but is now merely comparable to what a 500$ server can offer (thousands of private key operations per second).


Does Java's implementation of OCSP and CRL checking handle intermediate CAs?

The source code seems to say yes. Get it from there; then look at the files in jdk/src/share/classes/sun/security/provider/certpath/. In particular, PKIXCertPathValidator.java implements the validation mechanism. In the doValidate() method, classes which will do the OCSP or CRL checking will be instantiated as OCSPChecker or CrlRevocationChecker, and they will be applied at the end on all certificates in the path (this is done by a PKIXMasterCertPathValidator instance).

Without looking at the code, this behaviour could have been deduced from the API documentation on java.security.cert.PKIXCertPathChecker: the init() method explains quite plainly that all certificates in the path will be fed to the checker instance.


Can PE file have two or more executable sections?

Yes, it can, but it is atypical. Normally the compiler will make a section named ".text" with the correct permissions for executable code. But PE files in general can have multiple executable code section. A tool like PE Bear can tell you about the sections and their characteristics.

  How can we detect whether it is inject or not?

It's not clear to me what you mean by "it is inject." Do you mean that the PE tries to inject code into another process? If this is what you mean, then this could only be determined by reverse engineering and understanding the functionality of the PE. You could start by looking at imports. For example, if it is going to try and inject into another process it might import WriteProcessMemory, VirtualAllocEx, and other API functions related to memory reading and writing across process boundaries. Of course, these might be obfuscated in general so the imports might not be obvious.


Will there be a grace period for the CA change to mandatory 1 year?

There is already a grace period build in. To cite from digicert:

... Apple announced that beginning Sept. 1, newly issued publicly trusted TLS certificates are valid for no longer than 398 days.

Thus, this is only about certificates issued after Sept. 1. and it does not affect already issued certificates. This also means that there is nothing to worry about when hosting a site, since already issued certificates are not affected. Note that there was already a limit in place how long certificates issued by public CA should be valid, this limit is now only made shorter.


Do pharma hacks always redirect to attacker page or can it also be ads on the legit website’s page?

According to my knowledge, both scenarios can happen.

When a hacker gets access to your site, he or she can do everything they want, ranging from embedding spammy links to nefarious sites, changing the title of your pages, and even adding new pages.

However, I have lately seen lots of examples of attackers directing to the pharma page, located on the same site domain.

(In this example, a page created by the hacker and placed on www.example.com/xxxx/illegaldrug~~)

They also mess up your database.

This link illustrates the process of pharma spam and prevention very well:


It's possible to trigger a XSS in url context without this following caracter ' : '?

If, as it seems from your question, you control the entire tag, then you can try <a onclick="alert(1)" href="#">


How to configure SQLMap to attack JSON parameter?

Any luck with --delay?
    --delay=DELAY       Delay in seconds between each HTTP request

Note that something else might also cause 500 error code.


In theory, yes. In order to prove this, all you need to do is hash every possible output hash, and see if any of them result in the same value as was input.

This might take a while.

In practice, very few people use passwords which are themselves valid outputs for hash functions, since this would rewrite remembering a 30+ character string comprised of digits and the letters A to F (assuming a hexadecimal representation). Furthermore, the use of salt in modern hashing algorithms would further confuse the issue - the password would have to be part of it's own hash, and the salt be the remaining part.


REST Security and API Security are excellent topics of research.

This question and the answers provide good starting points to find great tools and techniques to test these interfaces -- API Security Testing Methodologies

If I were you, I'd avoid testing a REST interface or an API's security remotely, or via a black-box technique such as dynamic app security testing. What you want is to analyze the design decisions (this blog post is a great reference with .NET code examples and component recommendations) and/or perform a secure code review. One tool that I commonly use to perform secure code reviews is Find Security Bugs. For analyzing components, there is OWASP Dependency Check (with multiple language support), bundler-audit for Ruby, Retire.js (or Snyk.io) for JavaScript, and OWASP SafeNuGet for .NET projects.


You'll likely need to contact your hosting provider. It's possible that they'll upgrade it for you but on the other hand they may ask you to "upgrade" to a newer hosting plan.

AFAIK there's no way to change this via .htaccess as it deals with a higher level of the software stack (i.e. resource permissions and routing). The same is likely true of plugins; they shouldn't have privileges to alter the server configuration beyond what you would have.


Passwords are normally stored in /etc/shadow, which is not readable by users. However, historically, they were stored in the world-readable file /etc/passwd along with all account information. For backward compatibility, if a password hash is present in the second column in /etc/passwd, it takes precedence over the one in /etc/shadow.

Historically, an empty second field in /etc/passwd means that the account has no password, i.e. anybody can log in without a password (used for guest accounts). This is sometimes disabled. If passwordless accounts are disabled, you can put the hash of a password of your choice. You can use the crypt function to generate password hashes, for example perl -le 'print crypt("foo", "aa")' to set the password to foo.

It's possible to gain root access even if you can only append to /etc/passwd and not overwrite the contents. That's because it's possible to have multiple entries for the same user, as long as they have different names — users are identified by their ID, not by their name, and the defining feature of the root account is not its name but the fact that it has user ID 0. So you can create an alternate root account by appending a line that declares an account with another name, a password of your choice and user ID 0.


You need to add JSR223 samplers or Beanshell samplers to encode and decode reqest and responce, with help of open source third-party Java library from Bouncy castle.

Follow this steps to record application requests which is using OCSP:

Load Test OCSP With JMeter

Check this guides for more information :

Recording with JMeter Proxy


lock for asp.net developer using vs 2010 and win xp?

Typically in a high security environment removable media,  laptops and even cell phones are prohibited.  Employees are expected to work on their workstations provided by the company in the office and no where else.   This is not a problem software can solve,  it is a problem addressed with company policy.

If someone is bringing their own laptop there is virtually nothing you can do to keep them from making a copy of the code to a CD, DropBox account, or a million other methods of obtaining this information.

But there is a deeper problem.  If you are able to prevent your employees of making a digital copy,  they can still look at the code.  Every day that they work they will understand it better and they could just implement it on their own.  Its an issue of trust,  and you have to trust your employees to some extent.


What's the difference between VPN over TCP vs UDP?

A VPN is for wrapping raw IP packets into some kind of "tunnel" between two sites (one of the site being possibly reduced to one computer, i.e. yours). TCP is a protocol which sits on top of IP, and uses IP packets (which are "unreliable": they can get lost, duplicated, reordered...) to provide a reliable two-directional channel for data bytes, where bytes always reach the receiver in the order they were sent. TCP does that by using a complex assortment of metadata with explicit acknowledges and reemissions. Thus, TCP incurs a slight network overhead.

If the VPN uses TCP, then your own TCP connections will use IP packets sent through the VPN, so you end up paying the TCP overhead twice. An UDP-based VPN thus has the potential for slightly better performance. On the other hand, the cryptographic protection of the VPN requires some state management, which may be harder for the VPN implementation when using UDP, hence it is possible that the UDP-based VPN has an extra overhead to contend with.

Therefore, the performance situation is not clear, and you should measure.


Having worked with RESTful Web Services doing code-review and code-assisted app penentration-tests on RESTful apps that were over 3 MLOC, I can tell you that the problems outlined by John Wilander in REST and Stateless Session IDs is the dominant, growing problem. If you do not have this problem (which is a very big problem) in your RESTful Web Services, I would be shocked. It basically makes REST a security nightmare. If you follow John's advice and implement sessions with SSL/TLS, you have solved your first and primary problem. I picture this as a very large application development project.

Additionally, many components of such an architecture may be at risk. Chris Gates has done a lot of research on the public facing OAS, such as his recent column on Oracle Web Hacking, which includes a link to running code for Metasploit modules on his git repo. Sensepost released a tool (go-derper) and work against memcached at the last BlackHat-US/Defcon.

Finally, RESTful services most certainly have issues with SQL injection, DRO, CSRF, and XSS just like normal -- and the occurrence of stored versions of those injections would dominate direct/reflected attacks.

The problem with REST vs. SOAP is that SOAP usually produces a WSDL. REST could have a WSDL (with WSDL 2.0) or a similarly described WADL. However, this is unlikely, and without a list of entry points, it is difficult to test RESTful services. One would need either the source code, the documentation, or an existing test harness. SOAPSonar is a commercial option, while WS-Attacker remains one of the best current open-source options for testing.

I could see how some Firefox / Chrome plugins and/or web proxies (e.g. Fiddler, Burp, Web2Proxy) could also be useful, but this would require some significant investment in time to manually build test fixtures. If an existing test harness (e.g. soapUI, HttpUnit) is available to the tester(s), then these tools can be run through a web proxy, preferably one that supports XML/JSON like Web2Proxy, Web2Fuzz, AppCodeScan, and wsScanner (which are discussed in Shreeraj Shah's book, Web 2.0 Security - Defending Ajax, RIA, and SOA).

XML itself can be tested using tools such as Untidy, by the same author as W3AF, which has its own proxy called spiderMan (probably great for testing REST if implemented correctly). I'm not sure if Acunetix WVS (the most recent release, which was last week) supports proxying in the way that Netsparker Pro does (or Burp Pro Scanner), but if it does then Acunetix may be the best tool to test for the stored injections, as I hear it has great support for these types of checks. If anyone has a license for the full version of Acunetix WVS, please let us know. The AcuSensor technology would also be very useful here, as would HP Fortify PTA -- especially since the entry points are unknown.

In other words, testing RESTful services with black-box methods and technologies is bound to fail. The problem with identification of entry points, even with source code, is that many RESTful services are often configured and developed with code indirection technologies, such as several well-known Web 2.0 and Web Services patterns -- as well as Dependency Injection, IoC, AoP, et al. Worse, there are often several levels of this indirection, with no Views folder or other simplification. This makes it additionally difficult to utilize automated security-focused static analysis tools (e.g. LAPSE+, CAT.NET, Yasca, Graudit, FindBugs, CodePro AnalytiX, FxCop, Fortify SCA, Checkmarx CxSuite, Appscan Source Edition, Armorize CodeSecure, Coverity, Klocwork, GrammaTech, and many others). Cigital has a solution called ESP which is considered best-practice for large-installation, SOA-based Enterprise app portfolios (note that ESP is usually backed by several app pen-testers year round who know how to manually review source code as well as identify complicated runtime analytics of application layer vulnerabilities -- so it's not meant to be used solely as a factory).

In summary, it will almost certainly need to be manually reviewed with all major and minor build components available to the reviewers.


How is end-to-end encrypted data stored in a database?

Storing encrypted information in the app's database comes at the expense of inability to use power of SQL to retrieve/store information in a convenient way. Encrypted data can not be indexed.

Because of that in order to search for a specific thing the application's server (or the app) needs to retrieve the whole block of data, decrypt it and then find what is needed.

  the encrypted data (e.g. chat message) simply inserted into the database under the respective column and the relational ID is left in plain text

Your app needs a way to retrieve encrypted data related to a certain user. If you store plain user ID, the retrieval process becomes simpler. If all fields of the database are encrypted you lose some usability because data retrieval process becomes harder. You will need to build your own lookup table in the app that would help to store/extract a chunk of data that you need.

But if you store plain user ID and all other data is encrypted and your data transmission process is also encrypted all the way, it should be very hard to map a certain user ID to a real user.

The database encryption prevents data disclosure in case of breach and makes it impossible for database administrators to snoop on your data. So, even if they see plain user ID in the database and can see how many message a certain user sent it is still very hard for them to correlate it to a real user.

How far do you want to go with database encryption (plain vs encrypted data) depends on your threat model.


Tools and approaches in order to teach software security?

As it happens there are load of resources for this kind of work.  for web application items, I'd recommend the OWASP list which has a large number of options.  Personally I've used Juice shop and the Railsgoat , both of which I thought were very good.

For the other vulnerable systems list, I'd suggest looking at somewhere like Vulnhub which has a fair few things which could be useful.

also you might want to look at metasploitable


Is there any history of a major attack using password reuse?

The attack against HBGary is a famous example of an attack made easier by password reuse:

  Neither Aaron nor Ted followed best practices. Instead, they used the same password in a whole bunch of different places, including e-mail, Twitter accounts, and LinkedIn. For both men, the passwords allowed retrieval of e-mail. However, that was not all they revealed. Let's start with Ted's password first. ... his ssh password was identical to the cracked password he used in the CMS. This gave the hackers immediate access to the support machine.

I don't know if you consider this attack large-scale, but it was definitely large impact to compromise a famous security firm, publish its internal emails etc.


Is there a point to using user certificates instead of only using machine certificates?

TL; DR - Deploy user certificates and uncheck the allow private key to be exported option when deploying them. For added security, require users add a password to the private key.

Discussion

  I've seen that user certificates can be stored on the user's computer just like machine certificates would. I understand it would be very secure if the user had placed his private key on a smart card or USB, cause then it would always be with him, like on his key-ring alongside his house and car keys

If a user loses their smart card or USB stick, the certificate is compromised. It is much more likely that a user loses physical control of either of these keys, thereby compromising the key.

A USB drive has zero protection against exporting a private key. At least a smart card does not allow the private key to be exported once it has been written to the card.

  But if you're not using tokens then the user certificate will be installed on the user's computer. That's far less secure than him just using a password to get authorized to the network.

Depends on the password. A 47 character randomly generated password with upper, lower, symbols and numbers is going to be pretty strong. "Monkey" on the other hand...

From a math standpoint, user certificates are orders of magnitude more secure than passwords the average user will generally use. However, this depends on your password policy and user base, I suppose.

  But with certificates, he has to store it on the computer. So if someone gets access to his computer he can export the private key. Then voila, that someone can now authenticate to the network with his own device using the certificate and private key he got off someone else's device.

User certificates can be deployed in a manner that the private key is not exportable. Ensure that allow private key to be exported is unchecked.

For additional security, you can also add a password to the private key, but this lacks the convenience of automatic deploy via GPO. And, in all likelihood, you'll need to go around to each user and do this for them with domain admin and local admin privs.


Convert RSA public key to the right format

I believe the reason is that the CoreFTP is actually generating OpenSSL keys and not OpenSSH formatted ones.

Perhaps your question is already answered on Stackoverflow?

https://stackoverflow.com/q/1011572/643314

From Victor Matare on SO:

You can do the same with ssh-keygen:

ssh-keygen -f pub1key.pub -i -m PKCS8

will read the public key in openssl format from pub1key.pub and output it in openssh format.


Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters?

For Turing-complete languages, you can't detect what they're going to do or access ahead of time. You can try to detect certain things based on usage of various language-specific framework classes and keywords, but it's not easy.

Let's say you're trying to stop someone from calling alert() in Javascript. Consider the following:

exec(
  atob('dmFyIHQ9MSx4PTA7eD1NYXRoLmxvZyh0KTsgaWYoeDwxKXthbD9ydCgnZGVycCcpO30=')
    .replace(/\?/g,'t')
);

Can you really write something that always identifies alert calls? Nope!

The only way to achieve this is to provide the control at a low level, e.g. within alert() itself. Obviously this isn't ideal; can you hook every possible JavaScript engine in every browser? Again, no. So you have to go lower still - maybe hook all calls to the system API used to create new windows. Oh, but now you need to be able to tell the difference between an alert() message and a normal window.

Not as easy as it first might seem, is it?

This is precisely why most mandatory access control systems focus entirely on access to resources, rather than operations. You have to know what you're trying to protect against in advance, and you have to know how that resource is going to be accessed. As such, there's no generic way to do what you want, even on a specific language. You need to manually configure the restrictions ahead of time.


How does sending referrer HTTP headers protect against CSRF attacks?

To understand this, one first needs to understand what a cross-site request forgery is.

A Cross-Site Request Forgery is when the attacker has some script or embedded media on a website they control which makes any visitors to that website request a resource from a different site. That request appears to that other site in the context of the user. I could, for example, add an image with the url https://othersite.example.com/delete_my_account.php?really=true to my website. When you visit my site and are currently logged into your account on othersite.example.com, your browser will request that URL, which would cause othersite.example.com to delete your account.

But there is a catch: When othersite.example.com can read your referrer, it can see that this request is caused by someone interacting with a different site. There is no good reason why a website would have a deep-link to an URL which performs an action. When the other site reject requests without a referrer, that attack becomes impossible.

Regarding referrer spoofing: Keep in mind that the client which does the request isn't the attacker. The attacker is a website operator. The worst that operator can do is have your web browser execute Javascript in the context of their website. While there are several ways to make requests to other websites using Javascript, none of those APIs allows to fake the referrer.


Tracing IP's of visitors to website to get exact business location?

You are correct in your suspicion that attempting to do any level of useful individual user identification by IP address is going to be generally impossible.

Even if you can identify the IP block as being owned by a specific business, the contact information will be for a technical department that is the equivalent of a corporate ISP, and you will find them less than helpful if you attempt to use them to identify which of their 50,000 employees/contractors/guest wireless visitors happened to be on your website at a specific time.  If they even have that information in the first place.

What companies like Lean Forensics do, I'm assuming from what I see on their website, is something that you cannot.   They likely act like an advertising network, aggregating data and tracking users across the entire Internet, and gathering and buying information about those users.   Then, when users they know about access your website, they can uniquely identify them and associate them with data they've already gathered elsewhere.  However, it's also not going to be 100% effective.  They'll only be able to provide information on users that they both have information on in the first place, and can identify as specific users they're tracking. Since IP addresses are shared and can be reassigned, it also won't be as accurate as what you'd get with a typical ad-network that uses techniques like tracking cookies instead of IP addresses alone. Ethics and creepiness factors aside, it is, however, far superior to anything you'd be able to come up solely from the data you have in your logs.


Within AWS, you can create a VPC allowing you to define your own virtual network.

You can partition this into subnets. As an example, you could have web servers in a public subnet (effectively a DMZ network) and your internal servers (say databases) in a private subnet. You can use NAT to initiate outgoing connections from the private subnet to the Internet (say, for patching).

AWS provides security groups that are analogous to IP/port based firewall rules.

GCP provides similar abstractions for virtual networks, subnets and firewalls.


Is it responsible to sign an OpenPGP key without verifying person's identity?

There are no rules on your personal certification policy. In fact, RFC 4880, OpenPGP states:

  There are a number of possible meanings for a signature, which are
     indicated in a signature type octet in any given signature.  Please
     note that the vagueness of these meanings is not a flaw, but a
     feature of the system.  Because OpenPGP places final authority for
     validity upon the receiver of a signature, it may be that one
     signer's casual act might be more rigorous than some other
     authority's positive act. [...]

I already provided further discussion on the meaning (and vagueness) of certifications in "Is it okay to sign a PGP key without an IRL meeting?".

If you are sure about the software project's key, and also consider it might be relevant to share this attestation, providing a public certification might be a reasonable thing to do. Personally, I also do (but didn't do often, yet), using the very same "sig1/0x11" signature level. If you put deeper thought on what certification levels to use and have a more or less rigid definition, providing a certification policy ("What are you saying when you sign a PGP key?") might be helpful if others actually consider following your certifications in the web of trust.

If you use GnuPG and only want to issue a "private" signature which should not be shared with keyservers and otherwise exported, there is also the local signature (lsign) feature.