Can string comparison realistically be exploited in a timing attack on a web server?

Timing attacks are possible even if response times seem inconsistent, because you can use statistical analysis to filter out a lot of noise in the data. Average values are much more stable than instantaneous values, for example. A fixed delay (like the one introduced by the comparison) will be added to the average, while inconsistent delays (like the ones introduced by the network) will cancel out. Example:

Response times: 17, 20, 1, 15, 62, 35
Average: 25

Response times (+1 delay): 18, 21, 2, 16, 63, 36
Average: 26

So as you can see the fixed delay is detectable in the average value, and instantaneous spikes don't matter. Finding a stable average value might be difficult though, and it might require a lot of attempts (thousands or even millions of requests). Also the average value might not even be stable enough, and other statistical analysis might be taken into account.

This complexity makes remote timing-attacks impractical in many situations, although research has shown that they are possible within local networks. This means that an attacker might well try to use such timing-attacks once they have broken into your local network, for example. On the other hand, it might be impossible to use the same attack from a remote location, or it might not be worth it at all anyway, depending on several factors like the configuration of the network and your server. A remote attacker will therefore focus on other vulnerabilities to exploit. Also remember that you can avoid this problem by implementing some kind of rate-limiting in your server, banning any potential attacker after too many attempts.


The question asked is "Is it acceptable in this case to rely on IP as an authentication [mechanism]?"

The short answer is: It depends.

Let's start with a definition of authentication. Merriam-Webster defines authentication as

  ": an act, process, or method of showing something (such as an
  identity, a piece of art, or a financial transaction) to be real,
  true, or genuine"

So the questions to be asked in answering this question:

What is the information classification involved? This is the basis of 'acceptability' for any security mechanism.
How strong and reliable are the authentication and authorization mechanisms of the VPN in question?
How strong and reliable are the mechanisms in place ensuring authentic IP address usage?
What are you authenticating: the workstation; the individual users?
Is there a direct verifiable relationship between any given IP address and any given individual user?

Your individual answers to the questions above will answer your question for you.

At a high level, and without many of the details, it seems that we can say that if the classification of the information being accessed requires authentication of individual persons, then it appears that the use of an IP address with limited-to-no verifiable direct relationship to any given individual would not be acceptable.


How sensitive is information on a system's architecture?

This information is not sensitive.
An attacker would gain very little by knowing these facts beforehand. Many of them are either not relevant to their campaign, or trivial to detect remotely, even if the configuration is not published. In order to answer adequately, you may want to elaborate on what you mean by "break in". Is the attacker attempting to bypass authorization remotely? Do they have a local process running on the system and are attempting to elevate privileges? Are they trying to root a commercial embedded system that they have purchased and have physical access to? Hiding this information may slow down someone who is trying to jailbreak a commercial system for a short amount of time by forcing them to spend time reverse engineering it, but it will do nothing against an attacker with a local shell trying to get root.
There is only one situation where hiding certain information is beneficial, and that is when an attacker is attempting mass-exploitation of a remote vulnerability. Having your application withhold its exact version can decrease the chance that an army of bots scanning the entire internet will attempt to exploit you. This will not protect against anyone who is looking to exploit you specifically, however.
Details you are trying to hide

Processor family

The processor family itself tends not to matter. The overwhelming majority of exploits, of all kinds, will work equally well on Skylake as on Kabylake. If you're talking about processor architectures, then it starts to matter, as MIPS shellcode will not work on an ARM system, and vice versa. However, this is not something that should be obscured, as the majority of servers and systems in general are running x86, mobile systems tend to run ARM, and embedded systems often run MIPS.

Operating system

Whether or not the operating system even needs to be known depends on what is being exploited. If a web app is being attacked, the operating system may not even be relevant. A SQLi vulnerability in a popular web platform will work equally well on Windows, Linux, FreeBSD, Solaris, or any other operating system that can run the vulnerable application. If the attacker is trying to attack the system itself to elevate privileges, it may be necessary to know the operating system. This information can be obtained remotely through a technique known as OS detection, or OS fingerprinting.

Libraries used

There are some libraries that will generally always be used. You will practically never find something that does not link against libc. A program doing math will likely use libm. A program that accepts user input via CLI will likely use libreadline. There are not many exceptions. If an attacker is trying to exploit a program, they only need to know the libraries in use if they are exploiting a particular vulnerability in the library. It's easy to check which libraries a program needs, as the list is encoded into the executable itself. Various scripts like ldd can gather this information from an executable.

Application programming language

The programming language for a vulnerable program may matter, depending on the type of exploit that is being used. A language like PHP which does its own memory management (is memory-safe) tells you that you will not need to attempt a stack overflow, as memory is managed. A C program on the other hand may be vulnerable to such a bug, as it is lower level. Knowing the language itself is neither necessary, nor sufficient for exploitation. The overlap in knowledge between a person who knows enough about a program to exploit it, and a person who does not know the language it uses, is zero.

Standardised protocols used

Some protocols are more vulnerable than others. DCCP for example has a history of nasty vulnerabilities. Rather than attempting to hide the protocols you are using, it would be far better to disable the unnecessary ones, as an attacker can simply attempt a connection with said protocol to see if it is supported. If the connection fails, it is either unsupported, or the port is closed. Either way, attacking the protocol itself will not be possible if it is not open and supported.
Types of attackers
There are different types of attackers. For this answer, let's split up the types of attackers into local, remote, and physical, and see what position they are in to gather the information they need.
Local attacker
A local attacker is running a process on your system. They want to elevate their privileges, or move laterally to other users. They may or may not be sandboxed. A local attacker is one of the most dangerous, as they have access to any information the operating system willingly gives out.

Processor family - Unnecessary, but can be retrieved in /proc/cpuinfo.
Operating system - If they are running locally, they most likely already know the operating system.
Libraries - If they have access to the executable, then can run ldd or readelf on it.
Language - Checking the libraries in use gives away the runtime, revealing the language.
Protocols - Using the socket() syscall can allow testing if a given protocol is supported.

Remote attacker
A remote attacker is trying to compromise a server. Their only interaction with the target is over the network, subject to any firewall rules that may be in play. They want to gain unauthorized access to the system by exploiting vulnerabilities in remotely running services.

Processor family - Unnecessary to know, but can probably be guessed.
Operating system - Many tools can remotely reveal the operating system being used.
Libraries - Very few remote exploits need to know the specific libraries being used.
Language - If they know a service well enough to attack it, they know the language.
Protocols - An attacker can attempt to connect using a particular protocol. If it fails, it is either not supported or firewalled off. The attacker does not care about the distinction.

Physical attacker
A physical attacker has your device in their hands. They may be trying to reverse engineer it and jailbreak it to expand its functionality or access secrets it is storing. They can open the device, look at the labels on the components, dump firmware, and possibly even attach the CPU to a debugger. This is the most powerful class of attacks. There is generally no way to prevent a physical attacker from gaining detailed information about your system, given enough time.

Processor family - This can be determined by reading the CPU's datasheet.
Operating system, libraries, language, and protocols - Dumping the firmware reveals this.

Summary
In general, this information is either easy to find out, not necessary to know, or difficult to hide. There are far better ways to improve your security. Now, what you should do, rather than hiding the following:

Processor family - Make sure you are using a modern processor with valuable security features like NX, SMEP, and RDRAND. A good operating system can take advantage of processor security features to enhance your security. CISC systems are easier to exploit using ROP. Systems with out-of-order and speculative execution can be vulnerable to side-channel attacks.
Operating system - Use a secure operating system, kept up to date and configured securely. OpenBSD is more secure than an old Windows server. Linux with grsecurity is more secure than a poorly maintained CentOS system. A custom kernel configuration or whitelisted modules can allow you to disable unnecessary drivers and other risky features.
Libraries used - Ensure all your libraries are kept up to date. If a vulnerability is discovered in a library, update it and restart any application that is running and which links against it.
Application programming language - When possible, use a language that is memory-safe. It is harder to get things wrong when writing in python than it is when writing in C.
Standardised protocols used - Only enable the protocols you need. Unnecessary protocols may be exploitable locally or remotely. If you have whitelisted your protocols to only the core basics necessary to run adequately, exploiting you through a networking vulnerability will be much harder.

While there is no reason to reveal all this information (assuming you are not expecting collaboration, where revealing information can help people point out bugs for you to fix), some of the details you mention are either so irrelevant or so easy to detect that you would have to go to excessive lengths to hide that information. Simply disabling version information is one thing. Wasting effort trying to prevent someone from knowing if you are on an x86 system or a SPARC system is just unnecessary.
Some resources you might be interested in:

What is the best way to explain (a non-technical person) the risk of leaking version information?
Is it safe to reveal information about the OS and the software you use?
Hiding version - valuable or just security by obscurity?
The valid role of obscurity
Is displaying what server I am running on the error pages a security risk?
OWASP - Testing for Web Application Fingerprint


Not all apps in Facebook support HTTPS, so if you're playing games on Facebook or use other third party apps you will get a notification that these apps are only accessible via HTTP. When you proceed your connection will degrade to HTTP.


Can I use an AP "Bridge" with password to imporve security over an open, unencrtyped WiFi signal?

This would provide no additional security unfortunately.

If you use the new AP as a bridge you would not then be able to connect to it via WiFi, you would connect to it via Ethernet. It effectively connects your wired network to the WiFi network.

That aside because the network is open anyone can join the network. Once on the network (even if the AP bridge did offer you protection) they could still gain access to your traffic using a MiTM (man in the middle) attack like ARP Cache Poisoning. I've written a few articles on my blog about Session Hijacking and Code Injection which are a couple of attacks you would be vulnerable to.


Is it a good idea to let a database do a password check?

The "common solution" you mentioned has one glaring and obvious flaw: it can't use salt. If your hash has a salt (it should), then you need to fetch the salt before performing the hash operation. And if you're fetching the salt, you should just fetch the hash result at the same time. In fact, the two are typically stored in the same string.

Ideally, you should fetch the hash from the database and perform the computation on it in your application. Your bit about not wanting to worry about your applications supporting your hash functions is odd. Applications typically lead, not lag, databases in technology adoption.

Your solution of putting the password checking routine in a stored procedure is a bit crazy from a scalability point of view; password hashing if done right is extremely processor and memory intensive. Dumping that kind of load onto your database is ludicrous.

Stored procedures push computation from the web server to the database server, as do complex SQL queries. While that's OK in theory, in practice your database tends to be the least scalable part of your whole operation. Web servers tend to be (should be if you do things right) completely stateless, so running ten webservers takes no more work than running two. Databases are not so simple, and scaling up your database is one of the most difficult and expensive propositions most small websites face. This is immensely more difficult if you use any sort of database-side business logic. If you want the thing to be scalable, your application server should contain logic and no state, and your database should contain state and no logic.


how is my router being modified to include WAN port-binding items for Teredo and Spotify

Several protocols exist, which allow applications running behind NAT-aware routers to configure the router to make some redirections, i.e. to allow these applications to be contacted from the outside. See e.g. IGD and NAT-PMP. Without such specific protocols, applications which want to do direct client-to-client communications (e.g. Skype) need to resort to cruder tools like UDP hole punching.

Thus, your entries were added automatically, on behalf of the applications which asked for them. How to remove stale entries is entirely device-dependent. Simply rebooting your router might do the trick; or not.

From a security point of view, this highlights the fact that NAT is not totally equivalent to a firewall which blocks incoming connections. Applications which run on the machines behind the NAT and intent on doing some server-type actions can still do them.


How to explain buffer overflow to a layman

Imagine you have a list of people you owe money to.

Also, when you write over something, it replaces what was there before instead of writing over the top of it. (The analogy breaks down a bit here, because you pens don't work that way in real life, but computer memory does)
You pay someone a $500 deposit on a $5000 car, so you now owe them $4500. They tell you their name is John Smith. You write the amount (4500) and the name (John Smith) in the table. Your table now looks like this:

Later your table reminds you to pay them back. You pay the $4500 (plus interest) and erase it from the table, so now your table is blank again.
Then you get a $1000 loan from someone else. They tell you their name is "John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9999999999".
You write the amount (1000) and the name (John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9999999999) in your table. Your table now looks like this:

(the last 0 from 1000 was not written over. This is unimportant.)
When writing the name, you didn't stop when you got to the end of the "name" column, and kept writing into the "amount owing" column! This is a buffer overflow.
Later, your table reminds you that you owe $99999999990 to John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. You find him again and pay him almost 100 billion dollars.


How vulnerable is ADB (Android Debugging Bridge) over wifi now that WPA2 is cracked?

Some clarification: WPA2 is not cracked. The WPA2 protocol is mathematically secure however an implementation oversight in a few OS's allows for some nasty consequences with a local attacker. WPA2 can continue to be used for the foreseeable future so long as you update your devices.

ADB is fine so long as your device is >4.2.2 (which as far as I know is the only vulnerable range for Android?).

  ADB Authentication. Since Android 4.2.2, connections to ADB are authenticated with an RSA keypair. This prevents unauthorized use of ADB where the attacker has physical access to a device.

Unless the attacker steals the keypair their only option is to trick you into authorizing a new device which really isn't anything new or novel.

Source: https://source.android.com/security/enhancements/enhancements43


Can IMEI be tracked through IP address if cellular never activated on device?

The IMEI is transmitted only on the GTP open context packet on GRPS (requests, update, etc...), that is in general what is used on 3G/4G and different versions, but basically is there. So if you device don't sent that packets, general is when you use the radio interface, I don't think the IMEI is transmitted in other cases over WiFi devices or even Ethernet.


Can my customer's ISP trace who visited my business website?

Yes they can. If they are logging all outgoing connections (as for instance Turkish or Chinese ISPs tend to do) then they can easily correlate locally used IPs to your website.

SSL works at higher level of the internet stack. Furthermore even if you would obfuscate your IP address they would still see your customers DNS requests passing by. There is no way to obfuscate this unless all your customers start using Tor or another VPN solution which is not transparent to their ISPs.


What risks am I taking with a weak password on a laptop?

The risk posed by a weak user password is generally rather low, unless you're being attacked by someone really determined to get in to your wife's system (perhaps to gain access to other computers on the network?). This is for two primary reasons:

It's easy to defend against the password's use over a network:
While I don't generally work with Macs, it is my experience with PC's (as Linux doesn't, to my knowledge, have a comparable pre-installed service) that any and all services allowing remote access to anything (more recent versions have different services for remote registry, remote shutdown, remote desktop assistance, etc.) with an admin's password can be shut down/disabled without too much trouble (if you know what you're doing, locating the services takes MAYBE 5 minutes, and if you're prepared you can simply import a new security policy). The only reason I could think of to want someone's user password is to escalate your malicious program, which can be done easily enough without the user's consent.

It's difficult to GET the password in the first place: Brute-forcing over a network is VERY time consuming and very easy to defend against. To my knowledge, all realistic brute force attacks need to be performed against a hash (or encrypted data). Therefore, to even start trying to brute force her user password, your theoretical attacker first needs to access the aforementioned hash (obviously stored on her hard drive) first. If he has that, we can only assume that he could easily be doing something more efficient with his access (whether remote or physical) than looking for her user password (installing keyloggers comes to mind).

NOTE: The one reason I can think of to access someone's user password is a password-reuse attack, in which the attacker uses a sniffer to determine what accounts the victim has (sadly, this data usually not difficult to gather) and then attacks the weakest hash/encryption of their password, hoping that they use the same password on other accounts.


What is the best practice to save encryption and decryption method in an application?

If by "encryption method" you mean the cryptographic scheme used to encrypt/decrypt the data, then there shouldn't be any problem for them to be public. In fact, if you're doing it correctly, you should already be using something well-vetted like AES.

Always keep Kerckhoffs's principle in your mind

  A cryptosystem should be secure even if everything about the system,
  except the key, is public knowledge.
  The cipher method must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience.

The only thing that needs to be secret in your encryption scheme is the key.


Email password asked when trying to convert pdf to word, is this a phishing site?

As pointed out in the comments, this is most likely a registration form for a user account. Thus it is not asking your email account password but asking you to input a new password for this specific site, registering as a user.

This is most often done in an effort to make a service easy to use and reduce the so called "hassle hurdle" that usually entails lengthy registrations forms prior to service usage.

In this simple form, you can probably simultaneously register and use the service, but there seems to be UI missing to convey that information.

Nonetheless, because you hopefully do not practice password reuse, you should be fine just using a new password for this site and use it.

While it is not exactly clear to me as to why a registration is needed, this is probably dictated by their business model and/or legal reasons.


Does referrer header checking offer any real world security improvement?

It will pick off the low hanging fruit, but in general, it is not hard to spoof a header. I would say that if it has caused issues in the past, it is more than likely not worth the risk to your business apps.


How much does network security audit and patch work?

I don't think it is worth it to hire a 'security guy' for a 15 workstation company.  I think YOU are the security guy for your company (since you bought the router).  But,  if being attacked is something you are worried about and you think security is important then hire one.

This is a business question, not a security question.


Should generating gpg keys ever result in an identical key to an older key?

The chances of this happening by chance are zero.

You have either:

Found the old private key you thought was lost (hidden file?), or
Used a deterministic key generation mode which takes user-supplied entropy (passphrase). If you use the same entropy you will get the same key, or
You've got a completely borked install which always returns the same random numbers.

I am not familiar with the Seahorse GUI so I don't really know how likely these options are.

However I think it most likely that you only thought you hade lost the key because you didn't know where it was. I am guessing that Seahorse looked in a bunch of default locations and found it somewhere. By default it's in a hidden directory in your $HOME.


No it's not possible to circumvent this CSRF-protection in a classical CSRF attack.
Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection.
An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such a case the attacker wouldn't have to use a CSRF-attack to do what he wants, because XSS > CSRF.
I also found a related answer from 2016: How do defend CSRF against requests that pretend not to be browsers?
Which concluded:

"The attacker can not succesfully modify the User-Agent header unless
you allow her to do so."


Effect of Firefox's "Responsive Design Mode" on the browser's fingerprint

There is no single fingerprinting method. But assuming that the fingerprinting you fear tries to be as granular as possible it will not only include easily fakeable things like User-Agent header but will also include things like font rendering, canvas performance etc - see here for some extensive but still incomplete and somewhat outdated list of ways to identify a client.
In this case a system with the performance of a desktop, Linux specific font rendering but a reported screen size of an iPhone will likely stand out as even more unique than if the browser would have reported the real screen size.


Address Space Layout Randomisation (ASLR) is a technology used to help prevent shellcode from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures. Data Execution Prevention (DEP) prevents certain memory sectors, e.g. the stack, from being executed. When combined it becomes exceedingly difficult to exploit vulnerabilities in applications using shellcode or return-oriented programming (ROP) techniques.

First, let's look at how a normal vulnerability might be exploited. We'll skip all the details, but let's just say we're using a stack buffer overflow vulnerability. We've loaded a big blob of 0x41414141 values into our payload, and eip has been set to 0x41414141, so we know it's exploitable. We've then gone and used an appropriate tool (e.g. Metasploit's pattern_create.rb) to discover the offset of the value being loaded into eip. This is the start offset of our exploit code. To verify, we load 0x41 before this offset, 0x42424242 at the offset, and 0x43 after the offset.

In a non-ASLR and non-DEP process, the stack address is the same every time we run the process. We know exactly where it is in memory. So, let's see what the stack looks like with the test data we described above:

stack addr | value
-----------+----------
 000ff6a0  | 41414141
 000ff6a4  | 41414141
 000ff6a8  | 41414141
 000ff6aa  | 41414141
>000ff6b0  | 42424242   > esp points here
 000ff6b4  | 43434343
 000ff6b8  | 43434343

As we can see, esp points to 000ff6b0, which has been set to 0x42424242. The values prior to this are 0x41 and the values after are 0x43, as we said they should be. We now know that the address stored at 000ff6b0 will be jumped to. So, we set it to the address of some memory that we can control:

stack addr | value
-----------+----------
 000ff6a0  | 41414141
 000ff6a4  | 41414141
 000ff6a8  | 41414141
 000ff6aa  | 41414141
>000ff6b0  | 000ff6b4
 000ff6b4  | cccccccc
 000ff6b8  | 43434343

We've set the value at 000ff6b0 such that eip will be set to 000ff6b4 - the next offset in the stack. This will cause 0xcc to be executed, which is an int3 instruction. Since int3 is a software interrupt breakpoint, it'll raise an exception and the debugger will halt. This allows us to verify that the exploit was successful.

> Break instruction exception - code 80000003 (first chance)
[snip]
eip=000ff6b4

Now we can replace the memory at 000ff6b4 with shellcode, by altering our payload. This concludes our exploit.

In order to prevent these exploits from being successful, Data Execution Prevention was developed. DEP forces certain structures, including the stack, to be marked as non-executable. This is made stronger by CPU support with the No-Execute (NX) bit, also known as the XD bit, EVP bit, or XN bit, which allows the CPU to enforce execution rights at the hardware level. DEP was introduced in Linux in 2004 (kernel 2.6.8), and Microsoft introduced it in 2004 as part of WinXP SP2. Apple added DEP support when they moved to the x86 architecture in 2006. With DEP enabled, our previous exploit won't work:

> Access violation - code c0000005 (!!! second chance !!!)
[snip]
eip=000ff6b4

This fails because the stack is marked as non-executable, and we've tried to execute it. To get around this, a technique called Return-Oriented Programming (ROP) was developed. This involves looking for small snippets of code, called ROP gadgets, in legitimate modules within the process. These gadgets consist of one or more instructions, followed by a return. Chaining these together with appropriate values in the stack allows for code to be executed.

First, let's look at how our stack looks right now:

stack addr | value
-----------+----------
 000ff6a0  | 41414141
 000ff6a4  | 41414141
 000ff6a8  | 41414141
 000ff6aa  | 41414141
>000ff6b0  | 000ff6b4
 000ff6b4  | cccccccc
 000ff6b8  | 43434343

We know that we can't execute the code at 000ff6b4, so we have to find some legitimate code that we can use instead. Imagine that our first task is to get a value into the eax register. We search for a pop eax; ret combination somewhere in any module within the process. Once we've found one, let's say at 00401f60, we put its address into the stack:

stack addr | value
-----------+----------
 000ff6a0  | 41414141
 000ff6a4  | 41414141
 000ff6a8  | 41414141
 000ff6aa  | 41414141
>000ff6b0  | 00401f60
 000ff6b4  | cccccccc
 000ff6b8  | 43434343

When this shellcode is executed, we'll get an access violation again:

> Access violation - code c0000005 (!!! second chance !!!)
eax=cccccccc ebx=01020304 ecx=7abcdef0 edx=00000000 esi=7777f000 edi=0000f0f1
eip=43434343 esp=000ff6ba ebp=000ff6ff

The CPU has now done the following:

Jumped to the pop eax instruction at 00401f60.
Popped cccccccc off the stack, into eax.
Executed the ret, popping 43434343 into eip.
Thrown an access violation because 43434343 isn't a valid memory address.

Now, imagine that, instead of 43434343, the value at 000ff6b8 was set to the address of another ROP gadget. This would mean that pop eax gets executed, then our next gadget. We can chain gadgets together like this. Our ultimate goal is usually to find the address of a memory protection API, such as VirtualProtect, and mark the stack as executable. We'd then include a final ROP gadget to do a jmp esp equivilent instruction, and execute shellcode. We've successfully bypassed DEP!

In order to combat these tricks, ASLR was developed. ASLR involves randomly offsetting memory structures and module base addresses to make guessing the location of ROP gadgets and APIs very difficult.

On Windows Vista and 7, ASLR randomises the location of executables and DLLs in memory, as well as the stack and heaps. When an executable is loaded into memory, Windows gets the processor's timestamp counter (TSC), shifts it by four places, performs division mod 254, then adds 1. This number is then multiplied by 64KB, and the executable image is loaded at this offset. This means that there are 256 possible locations for the executable. Since DLLs are shared in memory across processes, their offsets are determined by a system-wide bias value that is computed at boot. The value is computed as the TSC of the CPU when the MiInitializeRelocations function is first called, shifted and masked into an 8-bit value. This value is computed only once per boot.

When DLLs are loaded, they go into a shared memory region between 0x50000000 and 0x78000000. The first DLL to be loaded is always ntdll.dll, which is loaded at 0x78000000 - bias * 0x100000, where bias is the system-wide bias value computed at boot. Since it would be trivial to compute the offset of a module if you know ntdll.dll's base address, the order in which modules are loaded is randomised too.

When threads are created, their stack base location is randomised. This is done by finding 32 appropriate locations in memory, then choosing one based on the current TSC shifted masked into a 5-bit value. Once the base address has been calculated, another 9-bit value is derived from the TSC to compute the final stack base address. This provides a high theoretical degree of randomness.

Finally, the location of heaps and heap allocations are randomised. This is computed as a 5-bit TSC-derived value multiplied by 64KB, giving a possible heap range of 00000000 to 001f0000.

When all of these mechanisms are combined with DEP, we are prevented from executing shellcode. This is because we cannot execute the stack, but we also don't know where any of our ROP instructions are going to be in memory. Certain tricks can be done with nop sleds to create a probabilistic exploit, but they are not entirely successful and aren't always possible to create.

The only way to reliably bypass DEP and ASLR is through an pointer leak. This is a situation where a value on the stack, at a reliable location, might be used to locate a usable function pointer or ROP gadget. Once this is done, it is sometimes possible to create a payload that reliably bypasses both protection mechanisms.

Sources:

Windows Internals 5th Edition - Mark Russinovich
An Analysis of ASLR in Windows Vista - Symantec
ASLR on Wikipedia
DEP on Wikipedia

Further reading:

Stack-based exploit writing - CoreLAN
Bypassing stack cookies, SafeSEH, SEHOP, HW DEP and ASLR - CoreLAN
Bypassing ASLR/DEP - exploit-db


Before encrypting text, would encoding it with non-std. chars (ex: Asahi Characters) make it more secure?

No,  it won't make it more secured if attacker already decrypted the data he will find the encoding type and simply decoding it it's not making it more secure just use a strong cipher AES with blocks mode of operation like CBC or CFB with 128bit block size and random 16byte key and random IV every time and your data is secured now!


Can you measure the entropy of an "easy to remember" password?

I didn't check your combinations formula (as I explain below), but if users choose between all possible combinations with equal probability, then yes, you just take the base-2 logarithm of the number of possible combinations.

But the most important part of a scheme like this is what I boldfaced: how do you get users to choose between all of the combination with equal probability?  The XKCD comic really fails to address that, and you see people too often fail to grasp that point.  There is however the Diceware method, an older version of the same concept, which addresses this problem by instructing users to throw dice as part of the process for generating a passphrase.

The other thing that you should contemplate is whether your scheme of putting additional symbols on each word is actually worth it.  The additional symbols aren't magical—they just increase the number of combinations, something you can do much more simply simply by using more words; any gain you could get for increasing s, you can obtain by increasing n instead.  This is why I didn't check your combinations formula—I'm skeptical of the value of the additional symbols.


Identifying website attack type (Meuhy.php)

I found the Meuhy.php file on 10 WordPress sites. I also found these additional files added to GoDaddy hosted sites:

suspended..php
wp_rmder.php
test.php

The above files all of the Last Modified date of May 5th or May 14, 2018.

index.php had PHP code injected into it, last modified May 19 and a Google HTML file for verification on the Google search console was added May 19th.

I was first alerted because a new owner of the domain name was added on May 19th. I noticed that 5 XML sitemaps had been added that day, each with approximately 40,000 URLs.


How hackers implemented DDoS attack with 602 Gbps?

It may be possible, but attackers usually relies on an amplification attack to ensure the traffic coming from the botnet is much more effective.

Amplification attacks are easily implemented on udp protocols where the source IP can be trivially spoofed as there is no three way handshake to establish a connection. If a udp protocol allows you to receive a large packet in response to a small packet you have an amplification. Past examples of these are DNS and NTP queries. The attacker then spoofs the vicitm's IP and sends out the requests, the much larger responses are then sent to the victim's IP causing the DDoS through bandwidth saturation.


Snowflake uses WebRTC. If you are also using a VPN, enabling WebRTC can expose your real public IP behind a VPN.

This varies with Browser and VPN.


All 4 WP sites hosted in A2 Hosting were hacked

As you said, it is possible that the server is vulnerable, so if your hosting plan is on shared hosting then it's the hosting provider's fault, and your websites are alright. However it's not easy to be sure about that. Here's a list of things I would consider:

Type of hosting. Is it shared hosting? Then you only need to make sure your home directory is clean, change every password (WP, cPanel, FTP, etc.), and check every setting in the hosting panel (like suspicious additional FTP accounts, etc.). But what if your hosting is an unmanaged VPS? Then it'd be a problem, you'd have to check everything, because you run the whole server (and you'd better nuke it from orbit).
Check every file. Supposing you are on shared hosting and you only need to check your home directory, you need to make sure every file is clean. Restoring from a backup might not be enough, because... are you really sure the backup is clean? One way to check if WP is clean is to download its original files (same version as yours), and compare them with your installation (with diff -rq for example). You can do the same for themes and plugins.
Check the database. This is hard. I don't know of a decent way to do this yet. There are probably some scanners available, specific for WP. Otherwise you need to check at least there aren't suspicious users with privileges in the user table. Then try to check if there is any JavaScript injected in posts, comments, etc. Something like grep -i 'script' might help, but it might not be enough and it might have too many false positives. As I said, I believe checking the DB is hard.
Contact the hosting provider. If you are pretty sure your website is ok, then the infection might come from a vulnerability on the server, which is run by the hosting provider.


Is it legal to publish viticim's password and email?

Its depends on your state (But it's similar)
It's Illegal !
 for example for state of kansas :

  Statute 21-3755: Computer crime; computer password disclosure;
  computer trespass. (a) As used in this section:

  (1)   "Access" means to instruct, communicate with, store data in, retrieve data from or otherwise make use of any resources of a

  computer, computer system or computer network.

  (2)   "Computer" means an electronic device which performs work using programmed instruction and which has one or more of the

  capabilities of storage, logic, arithmetic or communication and
  includes all input, output, processing, storage, software or
  communication facilities which are connected or related to such a
  device in a system or network.

  (3)   "Computer network" means the interconnection of communication lines, including microwave or other means of electronic

  communication, with a computer through remote terminals, or a complex
  consisting of two or more interconnected computers.

  (4)   "Computer program" means a series of instructions or statements in a form acceptable to a computer which permits the

  functioning of a computer system in a manner designed to provide
  appropriate products from such computer system.

  (5)   "Computer software" means computer programs, procedures and associated documentation concerned with the operation of a

  computer system.

  (6)   "Computer system" means a set of related computer equipment or devices and computer software which may be connected or

  unconnected.

  (7)   "Financial instrument" means any check, draft, money order, certificate of deposit, letter of credit, bill of exchange,

  credit card, debit card or marketable security.

  (8)   "Property" includes, but is not limited to, financial instruments, information, electronically produced or stored data,

  supporting documentation and computer software in either machine or
  human readable form.

  (9)   "Services" includes, but is not limited to, computer time, data processing and storage functions and other uses of a computer,

  computer system or computer network to perform useful work.

  (10)   "Supporting documentation" includes, but is not limited to, all documentation used in the construction, classification,

  implementation, use or modification of computer software, computer
  programs or data.

  (b) (1)   Computer crime is:

  (A)   Intentionally and without authorization accessing and damaging, modifying, altering, destroying, copying, disclosing or

  taking possession of a computer, computer system, computer network or
  any other property;

  (B)   using a computer, computer system, computer network or any other property for the purpose of devising or executing a scheme or

  artifice with the intent to defraud or for the purpose of obtaining
  money, property, services or any other thing of value by means of
  false or fraudulent pretense or representation; or

  (C)   intentionally exceeding the limits of authorization and damaging, modifying, altering, destroying, copying, disclosing or

  taking possession of a computer, computer system, computer network or
  any other property.

  (2)   Computer crime is a severity level 8, nonperson felony.

  (3)   In any prosecution for computer crime, it is a defense that the property or services were appropriated openly and avowedly

  under a claim of title made in good faith.

  (c) (1)   Computer password disclosure is the unauthorized and intentional disclosure of a number, code, password or other means of

  access to a computer or computer network.

  (2)   Computer password disclosure is a class A nonperson misdemeanor.

  (d)   Computer trespass is intentionally, and without authorization accessing or attempting to access any computer, computer

  system, computer network or computer software, program, documentation,
  data or property contained in any computer, computer system or
  computer network. Computer trespass is a class A nonperson
  misdemeanor.

  (e)   This section shall be part of and supplemental to the Kansas criminal code.

More : http://kansasstatutes.lesterama.org/Chapter_21/Article_37/21-3755.html
More : http://oits.ks.gov/security/policy.htm


Would HTTP Header injection allow for an XSS vulnerability if content-type is application/force-download?

You're probably right that I also can't think of a way to get XSS this way, due to the Content-Type: application/force-download header.

That said, once you can write HTTP headers, there is a bunch of dirty stuff you can do that is totally unrelated to XSS. Off the top of my head:

HTTP Response Splitting and smuggling
Adding another cookie header, which lets you force cookies into the victim's browser under the domain of the vulnerable site (I'm sure if you start overwriting legitimate cookies, then you can get interesting behaviours the next time the user connects to the legitimate site using the poisoned cookies).

If this was my pen test, I would probably stop here and file "HIGH - HTTP Header Injection". If the customer wanted a PoC, my next step would be looking through the list of HTTP Headers for one that I could do some damage with.


Using only password to authenticate user (no "username" field)

Main problem with using only the password is that you cannot apply salts.

In a normal, robust server which authenticates users by password, the passwords themselves are not stored "as is" but hashed. The password hashing process requires some care, because an attacker obtaining a copy of that file full of hashed passwords (e.g. through a SQL injection attack) can run a dictionary attack: this is "trying" potential passwords. Human users tend to choose passwords which are "words" in some language, or simple derivatives from that (e.g. appending one digit), hence the term "dictionary".

To make the task harder for the attacker, the password hashing process must:

be inherently slow by mandating, for instance, one million nested hash function invocations;
be salted: the salt is a parameter which alters the way the hashing works, and each hashed password has its own salt value. This way, when the attacker tries a potential password, he must first choose which hashed password he will target.

The username is the selector for the salt: when the server receives the username, it looks it up in its database, obtaining the hashed password and the salt value which was used to compute that hash (both are stored together). This allows the server to recompute the hash, starting with that salt value and the password which the user provided. If the server gets the same hash value than the one which was stored, the user is authenticated; otherwise, the user is rejected. Good algorithms for that are bcrypt and PBKDF2. I prefer bcrypt (but PBKDF2 is not bad).

Without a username, no salt. The server cannot know what salt value to use for the specific password, hence it must use the same salt (i.e. no salt at all) for all stored passwords. This allows the attackers to attack all passwords at once, which is much more efficient.

It is simpler to see it if you think about an online dictionary attack, where the attacker tries potential passwords on your server. With a username+password, the attacker must send a username and a password, and succeeds if the user with that name indeed has that password. Without the username, the attacker just sends a potential password, and succeeds if any user on the system has that password. If you have 1000 users, you just made the attack 1000 times easier.

Also, when a new user registers, he chooses his password. If that password collides with that of another user, then you have no choice but to reject the registration. At that point, the new user just learned that the password he wanted to use is already a valid password for another user -- you just turned the new user into a successful attacker, and he knows it...

Okay, I must remember not to answer question after eating but before the coffee. I just noticed that your "passwords" are actually UUID with 122 bits of randomly generated entropy. In that case, things will be better. We would not call these UUID "passwords", since they are not "words" and are not chosen by a human either, nor even remembered by a human. These are authentication tokens.

You will still want to do your transactions over SSL. Also, since the customers will not remember them, they will write them down, in files or on paper (more probably files, so that they may cut&paste it -- nobody wants to type whole UUID on a regular basis). This makes the secrecy of these UUID more difficult to maintain. Your clients will have to take responsibility for keeping these values secret; this might be a bit too much to ask of a typical client.


Is looking at certificate expiration date a valid way of detecting malicious websites?

No, it's not a proper way to check.  Long-lived certificates are largely falling out of favor because of the security implications, and are actually arguably less trustworthy than short-lived one.  The reasoning behind this is as follows:

Suppose you own a website and purchase a TLS certificate for it with a validity of 10 years.  Now assume that the key gets compromised on day one, and you never find out about this.  Whoever got a hold of the key for that certificate can now impersonate your website for the next 10 years.  If instead you had one that was valid for only 3 months, the amount of damage that attacker could do would be significantly less.

As far as actually checking whether a certificate is legitimate or not, there's not really anything you as a user can do.

Validity periods are out, because that's local policy.  Some people still want to pay through their nose for long-validity certificates, so you will still see such certificates in regular usage, especially among companies that have been using SSL/TLS for the longest (banks for example).
Issuance date is out too, for the same reason that validity periods are no good.  You might consider one right near the end of it's validity period to be questionable, but that's hardly going to be reliable.
Domain validation is out, as it's not hard for attackers to spoof the required DNS records (DNS is still one of the most insecure parts of the internet).
Extended validation is out, as it's largely a joke as most companies that provide it do it, and some popular companies just don't do it at all (largely because there really is near zero value to it for securing communications).

All the other checks you might do that look at the certificate itself are already done by your browser automatically (checking that the certificate is valid and hasn't been revoked, that the domai matches, and that the server has the associated key).

That said, you should be actively looking out for typosquatting, which may be a bit more obvious if you are looking at the certificate itself.  A better defense for this though is to make sure that your browser displays non-ascii characters in domain names in their escaped or punycode form.


Can a website steal passwords saved in my browser?

If it was that easy, we wouldn't be using browsers. However, if your browser has a vulnerability, then things like this may happen.
Keep browsers up-to-date and run script blockers, like no-script, to prevent this type of attack.


Can we mask encrypted traffic to look like real traffic

You are talking about stenography. Yes this is possible however if you are looking about doing this in an automatic fashion this becomes difficult because of communication of keys. This communication would easily be flagged and then blacklisted. Then you are back at square one. stenography is a heavily manual process, but is worth looking into and researching.


How are files in file container (posibly in archive file) encrypted?

Both ways are possible:  encrypting the whole archive or encrypting each file in the archive. Encrypting each file separately is more flexible because this way each file could be encrypted with a different key if needed and each file could be extracted separately, i.e. no need to decrypt the whole archive to get a single file. It comes with a bit more overhead though.
From the security perspective both ways can provide sufficient protection of the content if properly implemented.


Tweaks related to javascript execution in browser

According to my test, I have found that the payload is valid but is not executing in Chrome. That is because of Chrome's browser based XSS protection. You need to turn it off so it will execute in Chrome. In Google Chrome, some XSS attacks are prevented using this protection. For disabling Google Chrome's XSS protection open it using the flag below:

  googlechrome.exe --disable-xss-auditor

This will disable the XSS auditor of Chrome and the payload will work well.


encrypted lookup-keys for key-value store

I found the answer. Turns out what I asked for is called a Message Authentication Code or MAC. There are various implementations for it, based on hash functions as well as block ciphers.

HMAC is using hash(key || hash(key || message)) pattern with some additional padding.


What does Google do to prevent SQL injections?

SQL Injection doesn't work on Google because they don't use SQL for search - they use BigTables instead (something they wrote)

They do protect against injection in general, however, by using appropriate filtering and never creating queries by combining strings, but rather by passing parameters.  Read OWASP on SQL Injection.

They likely use a Web Application Firewall (WAF) at some level as well, just as additional protection against programmer errors.


Does SQL Server CE 4 decrypt data securely?

If you are serious about the security of your data you shouldn't be using SQL CE, but rather a full blown SQL instance running on a dedicated box. Whether it pages cleartext to disk is wholly irrelevant to the overall security posture of your application because you're running an embedded SQL server in your web server process.

To answer your question though: Windows has the power to persist your memory to disk and there isn't much SQL CE can do to stop it because the data is present in IIS memory.


How can scammers inject pop-ups onto target computers?

To bad that your grandfather got scammed by those bastards, anyway scam is known as "Teamviewer scam", and since stammers had an access to the computer, probably they installed trojan for later deception which will bring them more money.

Second scenario according to BleepingComputer is:

  In some cases, parts of the TeamViewer app has even been embedded in
  malware directly, as to simplify the process of stealing data via a
  legitimate communications channel, disguising the data theft
  operations under TeamViewer traffic.

After all in case like your grandfather's it is good to do next steps:

1. Call Your Financial Institution and Tell Them What Happened

Chances are, if you bank with a larger well-known bank, they will already have experience with this type of scam and will tell you exactly what they can do in terms of putting a security alert on your account, dealing with fraudulent charges, etc.

DO NOT WAIT TO CALL YOUR BANK, tell them as soon as possible. If you wait too long then they might not be able to help you with the bogus charges.

They will likely put a fraud alert on your accounts and issue you a new card. If they don't offer to do this, INSIST on it.

2. Isolate and Quarantine Your Computer

Unplug the affected computer's network cord and turn off its wireless connection.

If you installed the remote admin tool as they directed, then they could be rooting around on your computer accessing your personal files, even after the phone call is over. They could also install keylogging malware to record your passwords as you access your bank and other accounts.

Once you've disconnected the computer from the network, read our article: I've been Hacked, Now What?  for information on how to backup your data, wipe its disks, and reload your computer. If you're not comfortable doing this on your own, consider taking your computer to a reputable local computer repair technician.

3. Monitor ALL of Your Accounts

You may want to consider signing up with a credit monitoring / identity theft protection service so that you can be alerted if and when scammers try to use your personal or financial information again.

4. Alert and Educate Your Friends and Family About This Scam

Even though this scam is affecting millions of people, there are surprisingly a lot of people who haven't heard about it and are still falling victim to it. Spread the word and share this and related articles with your friends and family. Educating people is the key to stopping this type of scam.

5. Change Your Passwords

After you ensure that your system is free of malware and keylogging software, change all your important passwords.

Make sure to choose strong passwords when creating new ones.

Source


How can I recover from a hacked WordPress site and prevent future attacks?

When compromised, the best bet is to nuke it from orbit.  Remove all files from your site, reload from a known clean image.  If you don't have a known clean image, re-install fresh and migrate over the DB records after verifying that they are valid.  Move image assets and any custom assets after careful review that they have not been compromised.

Make sure to keep your server patched and only use reputable plugins.  Make sure that your folder permissions are set correctly so that the public can not write to your wp-content folder.

It is also probably worth using the WordFence addon as an added security mechanism. While it won't catch everything, it will scan popular plugins to make sure they have not been altered.  This would likely have detected your second compromise, but it is not as sure as nuking from orbit or manual code review.  It will also help provide notification when WordPress or an Addon is out of date.


The worrying part is that the page includes resources which are not secure. Since this does not happen for me I don't expect a fault by Paypal itself. This can also not be done by a man in the middle attack so I expect the problem inside the browser. I expect that you have a browser extension which causes this problems.

Such extension can be innocent and still cause such errors but it can also be harmful (i.e. man in the browser attack). Note that in the past seemingly innocent extensions turned to the bad site later. Such a browser extension has full access to the page and could modify it or just grab the data (password) you enter. Therefore I would recommend to disable any extensions you have (only reinstalling the browser will not necessarily help) and also to change your access credentials for Paypal before an attacker uses these.


Microsoft password email reset link leads to different url?

I'm the Program Manager in charge of the password reset experience for Microsoft Online Services and wanted to clear up a few of the things you are seeing.  First of all, thanks for your feedback; we're always looking to improve our service, and comments like these really do help us to make things better over time.

The root DNS entry for our service is passwordreset.microsoftonline.com.  This DNS entry sits in front of a load balancer which directs traffic to region-specific datacenters which have different DNS records, hence the prs-scu subdomain (as an aside, as you perform your password reset, we also use this load balancer to ensure that your session is highly available in case of a datacenter-specific issue).

Now, when we send the email to your account to reset your password, we dispatch that email through a shared email service that is owned by a different team at Microsoft.  This is the same email service we use to send notification emails and informational emails for Office 365 as a whole.

The reason you see a different link in the href portion of the URL (e.g. click.email.microsoftonline vs. passwordreset.microsoftonline) is because the service we use to dispatch our emails puts a redirect in front of every outgoing URL to prevent phishing attacks.  We chose to include the plaintext version of the url in the body to address the case in which a user's email client does not handle HTML properly.

If you'd like to discuss this further, or what else we can do to improve your experience in the future, please feel free to contact me at asteen@microsoft.com.


Is Entropy all that matters in a Password?

Passwords do not have entropy, only the method used to generate the password has entropy.

If the attacker knows you use a wordlist then they can use the same wordlist to construct their guesses. If you take off the last letter of each word in your generation list, and the attacker knows this, they simply take off the last in theirs. The entropy would be exactly the same.

Your technique may enable your chosen passwords to go under the radar in a non-targeted dictionary attack, however in any targeted attack they may discover how you generate your passwords and alter their wordlist accordingly (e.g. from other breaches that may reveal your password when it has been cracked, from public website posts, etc).


What are the compatibility implications of generating a new TLS key?

Everybody uses RSA. If you stick to RSA, you certificate should be acceptable everywhere. Use a 2048-bit key size. ECDSA is nifty and very hipster, but won't work everywhere yet.

A RSA key is a RSA key. However, a certificate is also a signed object, and a signature algorithm begins with some hashing. Thus, a certificate will contain references to a hash function. Some modern browsers have apparently decided to scream and wail and shout when they see "SHA-1" in a certificate; therefore, to avoid dropping out of fashion, you need to use SHA-256. This should work on XP since SP3 (but not before). Take care that this is about the signature on the certificate, so really it is the problem of the Certification Authority that signs your certificate.

Whether you sign your certificate request with SHA-1 or SHA-256 as supporting hash function, should not matter. The CA extracts the public key from your request, pushes it in the new certificate, and then will use SHA-1 or SHA-256 depending on its configuration, regardless of what you used yourself to sign the request. At least that is how CA are supposed to work; some CA do weird things at times.


Verification of certificates entails checking several dates with regards to "the current time" as known by the system which does the verification (i.e. your desktop or laptop). In particular, your system will try to obtain fresh revocation information (the CRL). If your system clock is off, it will not consider whatever CRL it can download as "fresh"; it may spew out scary warnings, in particular if it sees a CRL "from the future".

Also, in SSL/TLS, the client and the server inform each other of their notion of the current time. There again, discrepancies could be warned upon.

To sum up, changing your clock to accept a certificate which has expired may "work", but not "work well". This, of course, depends on the leniency of your browser with regards to certificate validation, so the best course of action for your particular problem is to test it. Create your own CA, issue a server certificate with an expiry date on the past, install your CA as a trusted CA in your browser, set the clock back, connect to a test server which uses your expired test certificate, and see what happens. Anyway, this would hardly be a reasonable setup for production uses (asking your customers to set their clock back is kind of, let's say, commercially suboptimal).


Should you use SELinux or an antivirus?  Yes.  SELinux and an antivirus perform complementary tasks, so using both is better than using one or the other.

An antivirus is a tool to find known threats.  It can look at a file and say "this is a virus", but it can't look at it and say "this is not a virus" -- the file might contain a previously unknown threat.

SELinux is a fine-grained permission system.  It can do things like enforce a rule of "the web sever cannot write to directories outside its dedicated storage area" -- this greatly limits the damage an attack can do, but does nothing to prevent you from running an infected program in the first place.

The two work together: the antivirus stops known threats, but can't deal with unknown threats, while SELinux limits what an unknown threat can do, but wouldn't recognize a threat if one bit it.


What are some ways to steal a password/PIN using this system?

It will be harder, but not impossible.

The flaw in their solution is that they think one have to take screenshots at the same rate as the monitors refresh rate to get a complete image set. One only need a sample of each of the images.

You only need a program that takes 2-3 pictures a second (at a random interval) and check the difference between these. If an user uses 15 seconds to enter the pin, the spyware have maybe 30 to 50 pictures, this should be enough to joint to a picture that can be read by OCR. Combined with the mouse movement the spyware have your pin.


Can symmetric key cryptography provide identification?

The whole point of all encryption is that it's safe for the attacker to get your ciphertext, because they don't have the key. This is true for public-key encryption as well; it's perfectly safe for you to broadcast your ciphertext to the world, and certificates aren't related to that in any way.

The reason you use certificates in public-key cryptography is to know that you're encrypting something with the right key, because the key is generally sent over an insecure channel. With symmetric crypto, the analogous concern is that the person you talked to when you exchanged keys was an imposter; however, symmetric key exchange requires a secure channel with whoever you'll communicate with later, and so you can work out identity issues when talking directly with them.

Once you've directly tied a key to them, you can use message authentication codes to make sure that a message came from them and not from an imposter. Unlike digital signatures, you can't prove anything to a third party; with a symmetric scheme you know everything the other person does, so you could forge a message that looks like their messages. That's not an issue when you're talking to them because you know you didn't forge a given message, but you can't take that and prove it to someone else.


PCI DSS Scope

For PCI compliance you need meet the security requirements for all the Application/DataStorage/Networking that manage the cardholder information or that it's connected to the environment where the cardholder data is stored/managed or proccessed.


How do I generate a word list from a known seed word?

I recently created a tool called PassGen that will do what you are talking about.  It basically takes a target words and generates a password list using common substitutions.

A basic example:

python passgen.py -f forgot

will generate 1024 passwords as shown below:

forgot
forgoT
forgo+
forgo7
.
.
.
FQR9QT
FQR9Q+
FQR9Q7

Hope this can help.


How can I block access to module for Firefox? (gmail accessing camera)

Firefox solution:

You can disable permissions for cameras by going to options -> privacy & security (or type about:preferences#privacy into the URL bar) and look under the permissions header. There you can disable for all website by default and whitelist etc.

Linux solution:

Disable the uvcvideo module by modprobe -r uvcvideo. This will disable until next bootup. If you want this to be disabled permanently you will have to add blacklist uvcvideo into the /etc/modprobe.d/blacklist.conf file.

I should also mention that using lsmod only shows if the module is open (doesn't necessarily mean it is capturing) at that point in time and you might not be able to detect cases where the camera opens, takes a picture and then closes over a short period of time.

Finer control:

If you need to sandbox just firefox then you'll probably need to look for a sandbox program or setup a virtual machine or some sort to run it in. I won't go into more detail here as I'm not that familiar with good choices.


Secure OAuth 2 flow for client-side or mobile app

It's not safe to save the client secret on the mobile, so I will work on question 3.

I don't a have a solution, but I will explain a alternative that could mitigate the risk of saving a client_secret into a mobile device.

An alternative that you can do would be the usage of installation credentials instead of client credentials. The client credentials  will have a parent relationship with installation credentials.

  Client Credentials 1
  Installation credentials 1
  Installation Credentials 2
  ....

The idea is to use a security channel backend to backend to generate installation credentials. You gonna need to create a service, where you receive a APP credentials and return a Installation ID. In addition, the mobile application owner will need to create a service where the user request a installation credential.

Basically,

Mobile APP -> BackEnd(Mobile APP Owned) --> BackEnd (OAuth Owner)

This solution doesn't solve your problem, but it mitigate a risk of expose secret. You will get a installation credentials and can use it on your OAuth flow. If some get the secret, it can impersonate only a single user. The attack will not scale.


Own RootCA and SubCA - Deploy chain to /etc/ssl/certs or just RooCA cert?(Ubuntu)

The path validation needs to end in a self-signed root certificate which means that it is not sufficient to trust the intermediate certificate only, i.e. trusting the root CA is required in any case.

If you additionally need to add the intermediate CA as trusted depends on the setup of your systems: Usually TLS peers provide not only the leaf certificate but also any chain certificates needed to verify the leaf certificate against the root CA. In this case you don't need to be explicitly add the intermediate CA as trusted since it is provided during the TLS handshake. Only in broken setups where this sub-CA is not provided in the TLS handshake it need to be otherwise known, i.e. added to the list of trusted certificates.


Is the connection between Gmail server and Apple server encrypted?

Let's see:

$ host -t mx gmail.com
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
[...]
$ telnet gmail-smtp-in.l.google.com 25
Trying 74.125.142.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP ab10si598143icc.38 - gsmtp
ehlo example.com
250-mx.google.com at your service, [24.114.93.99]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 CHUNKING

See that "250-STARTTLS" ? It tells me that the SMTP server which handles incoming emails for Gmail supports SSL/TLS, and is ready to use it.

If I try again with apple.com server, I also get an announced SSL/TLS support. Therefore, servers on both sides are apparently ready to use TLS and ought to use it when talking to each other.

That's about the best that can be inferred from the outside. You cannot really know whether a specific email will be protected with SSL while in transit between the two servers, or even whether a given email was SSL-protected, because that's not written in the email itself. Similarly, SSL protects against Man-in-the-Middle attacks only as long as the SSL client duly validates the SSL server's certificate, including revocation checks, and nothing tells us whether Apple and/or Google does that properly. Without such protection, SSL is good only against passive attackers.

Also, remember that SSL is only for data in transit, between two SMTP servers: within the SMTP servers themselves, emails are not encrypted, and won't be encrypted in the destination mailbox (an email service could encrypt emails before storage, in a way precluding decryption by the server itself; Lavabit was doing just that until it was shut down recently; but Gmail does not do that, in particular since they quite openly scan email contents in order to make targeted ads for each user).


Can converting a virus-infected webpage to PDF format still contain viruses

I don't think it's possible. Usually, the library will render only the visual part of the page into a PDF, and not the embedded javascript, needed plugins or anything else. It's basically a screenshot.
Although it's possible to a specially crafted HTML page crash the library, perhaps executing code because of this, it would not reflect on the resulting PDF file. Depending on the attack, it would not even generate any file.
But I don't think anyone would create a crafted page attack a library in a way that generated a crafted PDF to attack your PDF reader.


Remotely find out what access points a wireless device is searching for

There's a list of preferred networks (You can add networks manually o save them when you check the "Connect automatically" checkbox).

When a STA (Station/device/laptop/Smartphone) isn't connected to any AP it sends probe requests, looking for AP listed on it's PNL (Preferred network List) if any AP matches with what's on that probe request, it will replay with a probe response and the connection will start.

So, the idea on an evil twin, is to listen to this probe request (This only contain the SSID, not the encryption used) with an antennae on monitor mode, copy the SSID, start virtual access points (Obviously with the SSID you just got) with each authentication (Open, WEP, WPA and WPA2), and see on which it tries to connect. You don't need the MAC address, there's a feature on WiFi called Roaming which lets you connect to different AP (same netwok/SSID), so it's the normal scenario when there are multiple AP with different MAC address.


SSL-VPN shall have at least two interfaces, i.e. external (Internet facing) and internal (intranet facing). You should filter traffic both from Internet to external address (i.e. allow only https connections), as well as from internal to Intranet.

In your terms that would be DMZ1 (aka dirty dmz) and DMZ2 (aka clean dmz).


This question is, in part, “How do I get my phishing emails past spam detection?”  Answering that isn't really in our best interest and you shouldn't spend too much time on it.  Instead, get your sending server whitelisted locally so your test is not run through any spam filters.

The easiest solution is to use a well-known testing agency like Cofense PhishMe, Wombat, or KnowBe4, and they'll do the heavy lifting and walk you through the rest.  This may not be ideal if you have a really small budget and/or if this is part of a student project.

A good in-house phishing test must

Have permission:

Approval from an executive or director, not just IT or Engineering
Relevant infosec and netops teams should sign off on this test

Use external servers:

Send the test from an external IP address range
Bypass anti-spam scanning by whitelisting the test's sending IP(s)

Identify itself as a phishing test in its headers:

Add an X-PHISHTEST header with your contact info for escalations
Leaving this indicator allows security groups to safely ignore reports  The X-PHISHTEST header triggers a “phishing attack” verdict in some spam detection solutions and prevents the “free pass” for reported phishing reports from meddling with real attack detection.  Note the need for whitelisting above.

Have a good landing site:

Consider a vanity domain like <institution>-support.com
Embed each user address in the link's query string
Log users' clicks and the IPs they clicked from for your report
Tell users that they fell for your trap and educate them
Link or host content similar to the APWG's Stop.Think.Connect.
Reveal the test at the document root or without a query stringso security researchers can understand your intent

Bad phishing tests

Will get into trouble with testers' management
Can get larger accounts suspended
Might get caught as spam and therefore fail to reach the targets
Risk annoying yet not educating the user base
Will confuse anti-spam filters when trained as phishing

Answers to your specific questions

Where do I host this site and how do I send this email?

So long as you follow the above rules about a good test and a good landing site, you shouldn't run into problems. As noted above, it is a good idea to alert your network operators (this includes your web hosting company) before you conduct this test.

I've seen some free hosting sites. Do email providers give low reputation to such free hosting sites?

You're probably referring to spam detection systems, which are nowadays extraordinarily complex, pulling in as much metadata as possible and combining it all with lots of secret sauce and machine learning. You really want to bypass spam detection with whitelisting. Client-side anti-spam is rarely powerful enough to discriminate in the manner you're worrying about.

Also, for sending the email, should I choose popular email service providers like gmail, hotmail or should I use disposable email? What will increase the chances of the email reaching the users?

Again, you need to bypass anti-spam, at which point much of this doesn't matter. A cheap vanity domain like <institution>-support.com likely comes with the ability to send within your provider's hosted environment.

I consider GMail and Hotmail to be disposable. Many penetration tests register accounts like <institution>-support@gmail.com and use good friendly from names like <institution> Support (which is the only thing mobile email clients display).


Evil certificate authority in public-key-infrastructure

As Rook said, the statement "Bob requests Alice' public signature verification key from CA. CA returns Alice' key..." is incorrect.

Public Key Infrastructure does not require a CA to serve as a public key server.

What would actually happen is that Bob would ask Alice for her public key. Alice would send her public key directly to Bob, signed by the CA. Bob would use the CA's public key to verify the CA's signature and Alice's public key.

Yes, it is possible for a CA to issue a certificate in error. This could be deliberate or accidental. A government agency could compel such an action (or in some places, CAs are run by the government), or an identity thief could perhaps achieve that outcome.

This is a design "function" of PKI (I'm avoiding the use of the terms "flaw" or "feature"!) - it allows a third party to confirm identity for people who haven't previously met, at the cost of having to trust a third party.

Carl Ellison and Bruce Schneier identify this as the #1 problem in their article from 2000 - "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure"

  Risk #1:  "Who do we trust, and for what?" There's a risk from an
  imprecise use of the word "trust."  A CA is often defined as
  "trusted."

  In the cryptographic literature, this only means that it handles its
  own private keys well.  This doesn't mean you can necessarily trust a
  certificate from that CA for a particular purpose: making a
  micropayment or signing a million-dollar purchase order.

  Who gave the CA the authority to grant such authorizations?  Who made
  it trusted?

  A CA can do a superb job of writing a detailed Certificate Practice
  Statement, or CPS -- all the ones we've read disclaim all liability
  and  any meaning to the certificate -- and then do a great job
  following  that CPS, but that doesn't mean you can trust a certificate
  for your  application.  Many CAs sidestep the question of having no
  authority to  delegate authorizations by issuing ID certificates.
  Anyone can assign  names.  We each do that all the time.  This leaves
  the risk in the  hands of the verifier of the certificate, if he uses
  an ID certificate  as if it implied some kind of authorization.

  There are those who even try to induce a PKI customer to do just that.
  Their logic goes: (1) you have an ID certificate, (2) that gives you
  the keyholder's name, (3) that means you know who the keyholder is,
  (4) that's what you needed to know.  Of course, that's not what you
  needed to know.  In addition, the logical links from 1 to 2, 2 to 3
  and 3 to 4 are individually flawed.  [We leave finding those as an
  exercise for the reader.]


Malware spreading via installation media

I am not aware of anything that would compromise a installation media while the user is writing it. It's possible to do something like that, but it would be a very focused attack.

An attacker would need to know the installation file and the burning software. There are a lot of ways to create a installation USB media (dd, unetbootin, USB Image Writer, for example), so the attacker would need to monitor all of them, intercept the read or write, and compromise the request.

Possible, but it's easier to change the DNS and direct the user to a rogue download site.


Yes. You should always escape untrusted data. Here's an attack for your snippet (pseudocode):

<noscript>
<img src="<?php echo 'you should always escape everything,
                dependeing on the context. This context is url in an attribute,
                you should escape it appropriately. otherwise " />
                </noscript>
                <script>alert("you will be vulnerable")</script><noscript><img "' ?>" />
</noscript>


What's recommended for performance & security : Server as PC or Server as HDD

In theory a NAS (which I assume is what you mean by "server as hard disk") is no different from a traditional file server in it's operation. They are both computers running an OS with a bunch of hard disks. There is no underlying reason why one or the other might be more secure.

In practice, it all depends on you. A NAS comes pre-built, whereas you build a traditional filer yourself. So, if you are an expert, you can use the finer control you have over a traditional server to harden it against attack. However, if you are not an expert, it's much easier to make mistakes in setting it up and leave holes open for attack. A NAS is going to fall somewhere in the middle.

So, if you don't know what you are doing, a NAS is likely to be stronger out of the box.

If you do know what you are doing, then usually the decision of "NAS or traditional" is going to be determined by other factors, such as cost, reliability, capacity, ease of use, etc. etc. and you'll have to harden whatever you get.

If security is absolutely your number one priority and you do not care about anything else then you're probably going to want to build a traditional server yourself and hand craft every detail for maximum safety. But that is a very unusual requirement.


Is it secure to store confidential data on basic HTTPS AUTH?

Basic auth has a few issues that were fixed in digest auth, but they mostly don't apply since you're using TLS (which should handle replay attacks and encryption of the secret values).  It still might be a good idea to use digest auth anyways, because it's not worse.

Both of these authentication methods are still fairly primitive.  The most notable weakness is that they don't include any sort of brute-force protection: an attacker can try potential credentials as fast as your web server will process them.  This puts the onus on you to implement throttling in another system, like fail2ban.  Similarly, there are no direct audit logs, so you need to make sure that your web server is configured to log authentication accesses, and create a system that can filter and search these logs in case you need to check later to see.

Other than that, there are standard UX/security concerns that may not matter much in your case, since you only have two users.  One of these would be whether you have a shared password for everyone, or different user accounts; if it's the former, you have to (securely) distribute a new password any time you want to revoke someone's access, whereas with the latter you have to design a system that automatically updates the digest file and reloads your web server (or do this manually).


Should I be worried about these Drupal 7 username attack attempts?

I did some searching, and the closest thing I can find to what’s going on is outlined here. However, I don’t think that’s quite the same. It looks like your attacker is attempting to do command injections, one of which is pulling from pastebin, the other from GitHub. Seeing the sources that the attacker is attempting to include may give you a better idea as to what’s their trying to exploit, but keep in mind that is malicious code. Visit and investigate at your own risk taking proper precautions.

I don’t know how drupal works at its core, but I would hope that a GET request like what the attacker is using (since the parameters are in the URL) wouldn’t be capable of making any changes the attacker is trying to implement.

I would recommend looking through some system logs to ensure that there was no access to the server, and ensure that not only the CMS (Drupal) is up to date, but all of the plugins, and themes as well. If you do some searching around, you may find that even an up to date plugin may have vulnerabilities.


Are HttpOnly or Secure flags needed if no login?

It depens on whaty ou use cookies for.

HttpOnly makes the cookie unacessible from JavaScript. This is good for session cookies since it means that an attacker exploiting XSS can not steal them. However, in most situation you need to read the cookies with JS, and then setting the HttpOnly flag isn't really an option. So HttpOnly is mostly used for session cookies.

As for the secure flag, unless you specifically needs to send the cookie over HTTP you should always set it. Since the cookies are sent on all requests to your domain, even if they are not needed, it is easy to leak them if you just make one HTTP request. For instance, if you serve static images over HTTP and your cookies are not marked as secure you will send them unencrypted. If the cookies contain any sensitive data at all that is very bad.

So, to make a decision you need to understand both the purpose of these flags and what the cookies are used for. There is no blanket answer.


The PHP function shell_exec calls the fork system call to create a new process for ls. It seems that the call to fork is blocked by some security policy.

You can still execute any PHP code that doesn't use blocked system calls. So even though you can not run ls, you can still obtain a file listing by running something like this:

<?php
    print_r(glob('*'));
?>


Here's how the MongoDB id is generated: https://docs.mongodb.com/manual/reference/method/ObjectId/

The important bit is:

a 4-byte value representing the seconds since the Unix epoch,
a 5-byte random value, and
a 3-byte counter, starting with a random value.

The seconds since epoch is of course predictable, though there are many, many values to iterate through if you wanted to guess it.  That leaves the 5 byte random value and the 3 byte counter to predict.  That would take a bit of brute forcing, but it's not impossible.

The easiest solution may be to require user login before gaining access to the files.  If that's not possible for some reason, and the files are low value, I wouldn't worry about it, it's likely good enough.
If you want to be extra secure, a short lived generated random URL would be much more secure.


How to treat/hash ECDH shared secret to use as keys for AES?

In general, producing symmetric keys from some "secret" is called key derivation and uses a key derivation function. There are several KDF designs out there; many protocols define their own (e.g. in SSL/TLS). In fact, exploring the details of SSL/TLS would be a good idea (pedagogically speaking).

There is a current "push" for defining a standard construction, backed by the IETF, and it is called HKDF; if you are in need of a KDF then you could do worse than choosing HKDF (though it is relatively recent, it benefits from a robust cryptographic foundation and appears at least as safe as any other competitor).

If you need only a limited amount of key material (e.g. 128 bits), then you can simply use one of the usual hash functions (say SHA-256) and truncate the output. That truncation is fine is not a consequence of the hash function being, say, resistant to collisions; however, it is still believed to be adequately secure with non-pathological hash function designs, in particular SHA-256.

As for standards, yeah, there is one. It is called ANSI X9.63. Since it is not a free standard (legally speaking, you must pay so see it), amateurs and students don't usually consider it, so it does not percolate to opensource software. Its KDF is based on SHA-1; it basically computes SHA-1(secret || counter) for successive values of the counter, which, as far as KDF go, is not a very attractive design, though not trivially weak (I only have an old draft; newer versions of X9.63 might use SHA-256).


How safe is using JWT-based web application on shared computer?

The JWT has about as much protection as a cookie, except you're relying on the ability of the developer to handle the management of the token correctly. Putting the token is localStorage means it can persist across browser closes unless something is explicitly done to remove it (e.g. logout button, hook the close event to clear it). Alternatively sessionStorage works in a similar manner, but will automatically clear values when the browser is closed (the trade off being you can't share the token across browser tabs/windows).

Additionally, the ability to prevent things like XSS token stealing is reduced considerably because any JavaScript can query localStorage/sessionStorage, whereas the browser has built-in defenses to prevent JavaScript from reading cookies. On the other hand, you potentially get some inherent defenses against CSRF because the token must be added to the request manually.

So like all things, this all depends on your security requirements. Given all your caveats, it seems like it might be fine such that it's on par with cookie-based sessions. On the other hand, it doesn't necessarily protect against someone seriously interested in stealing your token. With that said, a browser isn't going to do much to help you in that regard anyway, so you might consider requiring all sessions be launched in a private browsing session/incognito/etc.


Assuming this user is legitimately trying to participate in a bug bounty, they should not be attempting drop a database via SQL injection.  This user sounds like a very inexperienced penetration tester, and I get the feeling that he or she may not fully understand the impact of some of the scripts that he/she is running.  The best course of action may be to reach out to the user, and let them know that some of their activities may not be in scope.  I would reference the terms and conditions of the bug bounty as a part of that communication.

If this is a malicious actor, you may want to consider reaching out to them with the same type of message.  They sound very inexperienced, and letting them know they are being watched may scare them off.  Beyond that it's a matter of monitoring your logs, blocking his or her IP, and making sure your software is secure. You could also consider contacting law enforcement. Keep your logs in case he/she does find and exploit a vulnerability.


Relevant answer to an existing question here: Can a captive portal be secured

You can generate a session key and store it in a cookie client side which contains a session token to authenticate the client to the Proxy (yes proxy!). (do make sure it's sent over HTTPS as otherwise it's completely useless)
The proxy does bring a limitation when it comes to other types of traffic such as SSH (taking out of scope that your users know how to tunnel traffic over HTTP). To solve this problem you can step away from the whole 'captive portal' story and try another authentication method like PEAP.
Note that setting up a good way of authentication is not easy as there are many ways of bypassing captive portals, for instance: DNS Tunneling, ICMP Tunneling, HTTP Tunneling

Apparently some routers have a 'Client Isolation' or 'Wireless Isolation' setting which may prevent devices on a network communicating with each other (mitigating any ARP poisoning attack).
Source: http://www.howtogeek.com/179089/lock-down-your-wi-fi-network-with-your-routers-wireless-isolation-option/
WPA2 Enterprise could also be implemented which encrypts traffic at a user level, using each member of the networks unique credentials (username and password).


Python's http.server library "basic security checks"

The problem isn't that there are known security vulnerabilities.

The problem is that there is not really an effort to address less common but critical vulnerabilities.

For example, many web servers will display error messages.  Until quite recently, Apache Httpd would include some of the request data in the error pages, which allowed cross-site scripting in default configurations of mod_proxy (CVE-2019-10092), with no way for the application developers to mitigate this threat against the site users.

The major web servers, such as Apache Httpd, Nginx, IIS, and Lighttpd each have hundreds of active contributors (or in IIS's case, a large corporate structure behind it), dozens of core developers who understand security best practices, and a team dedicated specifically to reviewing code for potential vulnerabilities.  As you can tell by browsing the CVEs of any of those projects, there are still things that people catch after versions are released.

The developers who write HTTP servers for programming languages are small sub-projects, developing tools to support the main product: The language.  There might be a dozen people who have contributed code to that tool, and one or two core developers on that project.

They do not have the resources available to search for vulnerabilities, so while there aren't any known vulnerabilities (or at the very least, it is very bad form here to point out known vulnerabilities that are likely to remain unaddressed), there are most certainly vulnerabilities in it, simply due to the complex nature of HTTP servers.

Some of these vulnerabilities might be extremely critical, such as allowing an attacker to have complete control over your server, including executing arbitrary code with a privileged account.  Such a vulnerability might not exist, but without a thorough code review—and with the large, red-boxed warning at the top of Python's documentation page—it is plausible that such a vulnerability might exist.

In your specific case, the CIO signed off on it.

It is the CIO's responsibility to ensure that risk assessments are done. As the sysadmin, it's your job to execute the company's officers' instructions, and your responsibility to ensure that the officers have the information they need to be able to make informed decisions.

Because of the boundary in responsibilities, the pushback that I would do is ask to see the risk assessment.  If the risk assessment doesn't include a very high probability (due to automated tools quickly finding the vulnerable server in hours) that the server gets infected with malware and used as a Command and Control repeater node for a bot farm, offer to help them make a realistic risk assessment.


Save private key in a database to share between multiple accounts

Your strategy has a few issues. It is a bit confusing, but I'll try to address:

Firstly if you use the output of a hashed password as the input to something else, then you'll not be able to change passwords, since after this the output of the hashed password would be different and would therefore end up being a different key.

Secondly, the premise that you don't trust the server implies that you cannot send passwords or keys in any way to the server, which would certainly be the case for web applications. So you can't use your password or the hashed password which is used as an AES key (considering that this is possible and feasible). Otherwise it is always possible for the server to collect enough information to recover all your keys.

The last aspect is a deal-breaker. Either you change your model and somehow trust the server, or you change your model to ensure that private keys never touch the server.


It is not likely a spoof (the attacker would not know if they were successful) but more likely a botnet cycling through its nodes to attack you. That's why it's a range of IPs. They cycle like this so that no one IP triggers a block.

Then is it also not likely that it is a local computer.

This behaviour is neither extraordinary nor unexpected. Just business as usual on the Internet. That's why exposing services like this is not recommended unless you have mitigations in place like only allowing certain IPs to connect to port 3389.


One of my open files turned into a list of URLs and codes after clicking a link on a phishing email?

The provided data looks like the SiteSecurityServiceState.txt file from Firefox.

It saves (next to other security related information) the HSTS-enabled domains and the data needed to implement HSTS on the client site.

This might be of interest (to know the sites you visit that do use HSTS and when the browser does allow a downgrade attack again due to expired HSTS headers) if you are to be targeted with such an attack.

Yet, this does not explain how this might ended up there.

If the site was able to bypass your browser and use a drive by attack that extracted those information and wrote to any recently saved file, you might have bigger problems (think: bot net, ransom ware,...) to worry than your HSTS-information leaked.

Make sure you didn't accidentally copy & paste that data there (or instructed a program to do so). If you didn't, you'd may have to nuke from orbit to be sure nothing is left on your machine.


Is it bad practice to prefix my hash with the algorithm used?

Many different password hashing systems do this. The type of hashing mechanism used should not be (and should not need to be) a secret. Kerckhoffs's principle says:

  A cryptosystem should be secure even if everything about the system,
  except the key, is public knowledge.

So, if your system is properly secure, it should not matter if the hash mechanism is exposed.


Distributed tokenization for credit card numbers

The first thing I would do is run any proposed solution past your PCI auditor to ensure your not going to deploy anything which will cause issues and put the company outside of PCI compliance.

It sounds like all you need is to have the card numbers tokenized in such a way that you will always get the same token given the same card number and there is no requirement to go back the other way? This would indicate you are after a hash rather than encryption. You can add a salt as well.

A lot would depend on what data will be associated with this information. If the only data you have linked to those hashes (outside your very secure vault) is the hash of the card number and no other personally identifiable data, such as card holder name etc, then a good hash, with a salt to increase the length, will likely be sufficient. Credit card numbers just by themselves without other information are not that useful. We already know the algorithm to verify valid credit card numbers and so could just as easily generate large numbers of valid card numbers. It is only when you can add the additional information, such as expiry date, card holder name etc that the data becomes really useful.

On the other hand, if your going to include additional sensitive data in your work, then I would be looking at ways to generate a unique token which does not rely on the credit card number - customer id or possibly a hash which consists of multiple fields - it really depends on the details of what your trying to do.

In general, think of the worst case scenario - don't assume your solution is safe. Instead, assume someone will be able to reverse engineer it at some point. then do a risk assessment of what the impact will be if they are able to do it. Then look at ways you can reduce that impact as well as ways to reduce the likelihood. For example, be very sure that all the data is actually needed - sometimes, just removing some bits of data can make all the difference. Also consider what controls you can put into place to alert you to a problem i.e. detection of unauthorised access, response to unauthrised access, etc.


Generating ECDSA certificate and private key in one step

This seemed to be the command you want:

openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650