Is using SecureString in combination with Xor considered secure enough for standalone Windows app? The environment is Windows. We are using 3rd party tools in our app, and for tools to work they require method call and pass a license key that is a string.
License.Import(string name, string email, string organization, string code)
Since it is an installable Windows app that might not have access to the internet, I don't see any solution, but to store license keys 'inside' the application.
The 'standard' way of protecting from memory dumping the key in C# is using SecureString.
However, when initializing SecureString I still need to feed the actual key into it. Which means that someone could decompile the code and get the strings from there. To prevent that I could use XOR with another value to obfuscate the key, but then I would have to store the XOR value somewhere which then could be decompiled and so on...

How to go around this hide the string inside the app circularity? Or is it 'good enough' to just SecureString + XOR the key, and accept that if someone will be determined enough he will crack it no matter what?

Nothing you can do about it. DRM is impossible.
You can try to hide or encrypt your keys, but this only delays the inevitable. The data is on the computer of the customer/attacker, and as such can be found by them. Let me illustrate with some examples:

Just leaving the string there
Even a casual script kiddie could run strings over your application and detect the license key.

Using SecureString
This doesn't stop attackers at all, as SecureString isn't designed to protect against what you want to protect. The idea of a SecureString is to have the user enter some secret data manually (usually a password), and then wipe it from memory when no longer needed. This means if an attacker dumps the process memory after the password was entered, it will not be in the process memory anymore. Since you need to store your license key permanently in the application, it's identical to scenario 1.

Encrypting the string and storing the key in the application
This is like locking your house and hiding the key under the doormat. A determined attacker will be able to find both the encrypted blob and the decryption key, and then manually decrypt the license key. Or, an attacker can simply debug your application and wait for the application itself to decrypt the key and then steal it from there.

Encrypting the string and storing the key on your server
This is the same as 3., except way more difficult for you to implement. An attacker can again simply wait for the application to decrypt the license key and then steal it.

Why is this so hard?
Many many software companies try to implement DRM, and all of them get cracked. The reason for this is because any software that checks whether or not a check succeeded can be manipulated by the attacker to always make the check succeed. It is essentially impossible to make software that the attacker cannot manipulate, unless you use a system that is completely locked down from the hardware up (iPhone, Nintendo Switch, etc.), and even then attackers usually find weak spots that circumvent DRM.


How secure is (permanent) cookie-only authentication? I'm making an webapp which have to maintain some user specific data, so authentication is needed. My app is not anything mission critical. As this is the case, I thought of removing the whole sign-up/sign-in as it acts as a big barrier for a visitor. Instead the authentication is based solely on cookies. When they access my app, a cookie is set and they are logged in. All their activities are stored in db across their cookie value. So whenever they visit again from the same browser, they will get their customized pages.
I know that they can't browse from another device, or if they clear cookies they can't recover account. Let's say these won't be problem for me, as there are going to be a handful of initial users. Incase if they face such trouble accessing, I could give them support.
So is it advisible to have cookie only authentication? And also leaving the cookie unchanged (permanent) is fine?

The security of your approach depends on the ability to protect the cookie against misuse by others - similar to how the security of credential based methods (i.e. username and password) depends on the ability to protect these credentials.
Only, nothing is known about your ability to protect the cookie. It is not known if you use HTTPS to protect against extracting the cookie by sniffing the connection. Neither is known if the cookie is httpOnly to protect against extractions by XSS attacks. It is also not known if attacks to the users system are part of the threats you need to worry about since of course this permanent cookie need to be somehow stored at the users system. And then there might be server side problems which might cause cookies to be leaked too.
In summary: it might be safe enough for your specific use case or it might be not. Too few is known about the use case and how the cookie is protected on the client, in transit and on the server.


Receiving strange data over SMTP where body is one line of random characters I have a website that has an smtp server open on port 25. There is no outbound functionality on the smtp server. We just parse attachments from our users, then 'queue' the email in a dummy queue. So essentially we drop the email after parsing it.

I've been noticing some weird traffic in the logs lately. Basically, I'm getting a bunch of intermittent requests to send email to a specific recipient, call it john@blah.com. The from address will be some random name, with the domain being the same domain as my websites url. So, things like joe@mysite.com, jim@mysite.com, kenny@mysite.com, etc.

I looked at the actual data that they are trying to send, and it's just a line of garbled crap like, 'xdf dznfsdf vsswu lfndfg qsdf'. Same thing with the subject line, just a line of garbled crap.

Also note that the requests are from different IPs, and if I look them up, I just get random locations like Russia, China, Australia, Qutar.

So, I'm trying to figure out the intention of the person doing this. I thought maybe they were trying to use me as a relay to send spam, and that would have made sense if there was actually a spam message in the email body, rather than just a line of random chars.

I also thought that maybe they're to find email addresses from people in my company, which would explain why the sender is somename@mysite.com. The only thing is, it doesn't look like they're using a true dictionary of names. It seems to be a small subset of the same names (like maybe 10-15 different ones being sent in no particular order)

Anyone have an idea what they may be up to?

It is probably a test to identify existing SMTP servers and/or acceptable users. So to say a first check before starting either some kind of attack or misuse (e.g. as relay).


How exploitable is a none JWT? A recent penetration test has discovered that my org is using the JWT authentication scheme that allows the 'none' algorithm. How exploitable is this in the real world?
I understand that the issue can be used by an attacker to change the payload to another user and then 'sign' it using the none algorithm that would be accepted, however the only real payload information that could be enumerated is the subject and a random value.
Would an attacker be able to brute force the subject field and gain access to another person's account? How realistic is this?

There's two aspects to your question:

Is a JWT token exploitable if it can be signed with the "none" algorithm?

Absolutely, yes.

Does it matter in your specific case where only a certain type of information is handled by the token that you know to be safe if tampered with?

Entirely up to you. This is the context that weighs the business risk of a particular issue.
From a development point of view, I suggest you disable the "none" signature algorithm and save yourself headaches and potential compromise when in the future you use the JWT token in a slightly different way and forget about this issue.
Here's a couple of resources:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
https://medium.com/101-writeups/hacking-json-web-token-jwt-233fe6c862e6


Sending encrypted data through android app I have an SDK for my web app, which user can integrate into his android app.
For authentication, we have an authkey. And it is sent as a POST or GET parameter when server-to-server communication occurs.
But in the app, I fear someone can just get the authkey by any method, while transmission. For that I thought of encrypting the authkey, but still, it will always be the same encrypted authkey and someone can just get ecnrypted authkey and can use the same to send data.

For avoiding this, I came with a logic, which I think is secure enough to send authkey with encryption and sending different encrypted authkey each time.
Here is the process.

I have a authkey, lets say ABCD1234, which I need to send
I generate a cryptographically secure random number, lets call it rand_number
I then encrypt my authkey with this rand_number, using 'aes-256-cbc', and call it as auth_token
I then encrypt the rand_number with my public key, and call it as time_token.
I then transmit this auth_token and time_token to my server

And server side:

I will decrypt time_token with my private key, and get rand_number
Will decrypt auth_token with this rand_number, and get the authkey.

Is this method secure enough ? Even if we disclose the whole process of encryption and sending data?

I don't know, but I have a feeling that, this would be an already exisiting method.

There are a number of problems with your scheme. Let's start with the most basic, though:
What you're trying to do cannot be done.
As I understand it, you're trying to hide a symmetric token (authkey), that is present in every copy of your app, such that somebody cannot write another client for your web app. This is impossible.

Your app has to contain the token. Anybody who can obtain the app - which, if it's on the Play Store, is anybody at all - can reverse-engineer the app to get the token out. Encrypting the token doesn't help; the attacker only needs to know the token in the same form that the app knows it.
Your app has to use the token. That use is implemented in code. No matter how you implement it, that same code will be available for an attacker to simply copy into their own app (even as a binary blob, if needed).

Ok, on to specific flaws in your scheme.
Replay attacks
Your scheme has no nonce, and thus the attacker can simply send the same auth_token + time_token pair that were captured from the app's traffic. The time_token will still decrypt to the same rand_number used to encrypt the authkey. This is the most trivial way to break the scheme; the attacker doesn't even need to know what the tokens mean.
Key size
You don't mention the length of the authkey, or how it was generated. Given that you explicitly mentioned this for the rand_number, but instead gave a very short example token for the authkey, I'm worried it might be too easy to brute-force. The attacker doesn't need to know what the decryption key is if the entire range of values to search is small enough.
Performance
Your scheme requires two asymmetric cryptographic operations per message, one client-side and one server-side. Asymmetric crypto is computationally quite expensive. Schemes that use it almost always either merely perform a single key exchange using it and then re-use the exchanged key for all actual communication, or are for asynchronous operation (like email or verifying download integrity) where performance is not important.
Re-implementing the wheel
If you're only worried about communication security (which is usually not actually sufficient when there's a static token involved, but it is the only threat vector you explicitly mentioned...) then you should just be using TLS (HTTPS, since the message format is HTTP). If you want to be extra secure, pin the server's certificate (or at least the subject public key info from the cert) in your app, so that an attacker can't do things like install a new trusted root certificate and use its private key to spoof your server's cert.


enable browser caching with HTTPS I understand that sensitive data should not be cached (ie, you dont want to cache an HTML file with all of your bank account details in it), but there are some things that HTTPS protected sites should be able to cache (Javascript, CSS, images, etc).  Tomcat doesn't seem to allow developers to explicitly define a file to be cacheable once SSL/TLS has been enabled, and I understand that even if they did the user's browser only uses an in memory cache for HTTPS sessions and discards everything once the session is over.  With the whole Web 2.0 thing thats going on, it seems to me that site operators would be interested in this ability to reduce loads on their sites (as well as page load time) while maintaining the "green bar" in the user's browser that gives us all a warm, fuzzy feeling inside.

UPDATE: removed bits about validating the cached files with an HMAC since it would be useless. If the attacker is exploiting some form of hash collision then it doesnt matter if the hash is calculated with a secret key or not.

Use this header in your https response:
Cache-control: public

Or add ", public" to your existing Cache control header.

Use the Cache control: public directive to enable HTTPS caching for Firefox.
Some versions of Firefox require that the Cache control: public header to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.

Source: Google Page Speed
The posting HTTPS Performance Tuning says in the section "Tip #3: Use Persistent Caching For Static Content" that Internet Explorer can cache static resources over https connections, too.


In what ways site administrators can detect incoming CSRF attacks? In what ways site administrators can detect incoming CSRF attacks? Is it possible or not?

You implement a CSRF token on every vulnerable form. When there is a CSRF error, it is logged, so you "detect" it (do note that it might be a false positive, such as having cleared the cookies). If you protect from CSRF attacks, I don't think it would be woth preparing such attack, as it won't work.
You might do some checks based on Referer header, which could allow you to detect certain CSRF attacks. Although that depends on the browser and settings, if there's no referer header (which could be suppressed by the attacking page on modern brower) you would receive no information.


Is an asterisk in sudo command specifications safe? This suggests that to restrict a user to a specific command with sudo a line like

%web ALL=(ALL) /usr/bin/service apache2 *

can be used. This particular line would restrict the user to running the mentioned program /usr/bin/service with the arguments apache2 *.

service apache2 status

works, just

service apache2

does not

I am wondering how dangerous this is. * can be many things of course. (I am not talking about exploiting the program with false input, this is obviously an issue.)

I assume that it is fine because sudo is not running a shell so nothing else can be done with that star. But making that kind of assumption makes me a little bit uneasy.

Any dangers that I should be aware of?

Different applications have a different understanding of what the asterisk means. Shells tend to treat it for parameter expansion, which can be quite complex in implementation and often results in security issues when used in scripts. Sudo, on the other hand, treats it simply as a catch-all wildcard for any further parameters in that single command. In other words, it allows the service command to run with any arguments that match the following regex:

^ apache2 .*

Adding it to your sudoers(5) will guarantee that you will be able to run any argument to the apache2 init script as root. Whether or not this is safe depends on how the service operates. There is nothing intrinsically dangerous about using an asterisk, but some commands will allow you to execute other commands as arguments. For example, permitting tar(1) with any argument could result in arbitrary command execution in the form of tar --use-compression-program=./evil.sh. I am not aware of any way to execute arbitrary commands, but that does not mean there are not any, or that there will not be any in the future.

It is generally assumed that a person who is able to execute a command that manages services is already in a privileged position, so there will be little attention put into ensuring that the apache2 init service or the service-managing commands cannot be abused when run as root.

If you consider this "exploiting the program with false input" and thus out of scope, it is safe. The sudoers entry will not allow you to, for example, run service apache2; ./evil.sh as root.


How does a mobile wallet vouch for credit card data? I just recently learned that vendors almost never store credit card data but instead receive a token from the payment processor that they then can use for future payments.

I thought this is also how mobile wallets work: The mobile wallet app stores the token on the phone and shares it with vendors that the user is shopping at, thus providing them with payment authorization and identification. But then I learned that the token only works for the party it was issued to by the payment processor.

So how/what does the mobile wallet communicate with/to a vendor when e.g. paying with NFC, if it can't share a token?

Different mobile wallets work in different ways.  This article from 2014 has a good overview, from which I've taken the quotes below.  As far as I know, nothing major has changed since then.

Google Wallet

  [Google Wallet] issu[es] the customer a Google Wallet Virtual Card. This Virtual Card is issued by Bancorp Bank through Google, and it essentially acts as an intermediary between the customer's preferred card and the merchant.

  ...

  Instead of having your Chase-issued Visa card information sent from the merchant's terminal to the merchant acquirer, the Google Wallet Virtual Card requests the funds from your preferred card, and the Virtual Card information is then sent to the merchant, who subsequently sends it on to the payments processor. From there, that information is processed as a traditional card's information would be.

In other words, when you load a card into Google Wallet, you're choosing to use it as a funding source for yet another (virtual) card, which is what actually gets sent to the merchant.  There's no direct link to your card, so your data is safe.

ApplePay

  When you first set up Apple Pay, [you send the card data to Apple]. Apple next “sends the encrypted data, along with other information about your iTunes account activity and device (such as the name of your device, its current location, or if you have a long history of transactions within iTunes) to your bank. Using this information, your bank will determine whether to approve adding your card to Apple Pay.” In a sense, this setup process is like the initial authorization in a traditional credit card payment. In a simple credit card transaction, card details are sent to the bank for authorization, and an approval comes back to the merchant that lets the transaction go through.

  The Apple Pay setup, however, appears to be the first and only time your real credit card information is passed around between Apple and an issuer. Once the information gets to the card network, it's decrypted, and the card network issues a token called a Device Account Number (DAN). The DAN is device-specific. The card network sends this DAN to Apple along with other information “such as the key used to generate dynamic security codes unique to each transaction,” according to Apple's support page.

In other words, Apple works directly with your bank to generate a special token that is unique to your device, and then you use that as payment through any merchant because the issuing bank will honor it as valid.

TL;DR

Apple works with banks to generate a token that works like a card (rather than the merchant-specific ones mentioned in the question), and directly charges your account.  But if the bank doesn't support it, you're hosed.

Google Wallet issues you a new virtual card from their partner bank, and then that bank charges your real card before authorizing any transaction.


How can I safeguard myself if share the same router with the people living in my apartment I share the same wireless router with some other people living in the same apartment. I want to safeguard my privacy and also not be held liable for their internet activity. The modem from the ISP only allows connecting one router to it. What can I do in this case?
Will connecting another router to the current router or changing the router configuration help me?
EDIT:
I would like to add that I own the router and not the other way around

To protect your own communication with the internet against sniffing by other on the same local network you can use a VPN, i.e. the typical VPN for private use which starts the VPN connection at the local system and has the VPN exit somewhere on the internet, outside of the reach of the other users of the same router and of your ISP.
Protecting yourself against liability issues this way is not possible this way though. All users behind the same router share the same external IP address and thus everybody able to use this WLAN (i.e. knowing the password and being locally present) will be suspect. While the external sites will see only the IP address of the VPN exit and not your original external IP address when using a VPN, it is likely impossible to prove that you've actually used a VPN all the time.


OFF Pocket or switch off your phone? OFF Pocket:

OFF Pocket is a "privacy accessory for mobile phones to block all signals".

To use the OFF Pocket simply place your phone inside the case and close it. Your phone is now OFF. Untrackable. Unhackable. Undistractable.

link: OFF Pocket on kickstarter

Why better to use this accessory than switch off my mobile phone? Is there any communication while my mobile phone not working (batteries out)?

I'd say that the off pocket isn't any better than powering down your phone and in terms of usability it's possibly worse, as some phones will run their batteries down quicker when out of coverage.

Oddly given their target marketing the best use I can think of for this is for law enforcement to use it when acquiring mobile phones for forensic review as it stops remote wipe while not powering them down which could lose valuable information.


Are Whatsapp and Signal truly secure and user-privacy friendly? I have been learning the famous "SIGNAL MESSAGING PROTOCOL",  Its brilliantly designed and perfectly secure , but I doubt on its implementations

Famous messenger services like Whatsapp and Signal claim to have implemented the
e2e messaging protocol for message privacy , but where are the private keys (of users)
stored?

I am pretty much sure that the private key isn't stored in the user's device because ,
I tired sending a few messages from device "A", switched it off, installed the same
app in another device "B" and logged in with the same account. If the private key had been stored in device "A" then , I must not be able to read the messages from device "B" which I had sent through device "A" , but I was able to !!

So its pretty obvious that the private keys too are stored in the app's cloud.

If the messaging service provider too had access to the private key , then they could read any sorts of information transferred between me and the receiver through the app.

And whatsapp claims the following in their signal protocol implementation

Are their claims true?

Just Curious.. I am beginner, please correct me if my interpretation is wrong

WhatsApp has a known security design loophole.
The private keys are indeed stored on the user's device. When you install WA on device B, you will be taking ownership of your account again.
At this point, it's not possible to decrypt messages sent to phone A. Unless...
For user experience reasons, WhatsApp will actively re-encrypt and re-send undelivered (one-checkmark ✔) messages to device B with the newly created keys. This is known as resend vulnerability.

WhatsApp asserted the key retransmission process is a design decision — intended to minimize the risk of messages being lost in transit when, for example, someone gets a new phone or swaps out their SIM.

To explain, the following happens. Please note that there is some simplification:

Alice sends text to Bob, who is offline
In order to do so, Alice gets Bob's public key from WA server. Specifically, she obtains a set of keys to use in the future
Alice sends WA the encrypted messages and obtains the first check
Charlie pwns Bob's account, and notifies WA server
WA has still messages pending from Alice that can't be decrypted by Bob Charlie, so informs Alice
Alice will pull the new keys for Bob Charlie. Since Alice has only one checkmark (message sent but not delivered), she assumes Bob never read those messages.
Without user confirmation and before asking for additional identity checks, Alice re-encrypts and re-sends messages to Bob Charlie
Bob Charlie downloads the new messages encrypted with Charlie's public keys
Alice gets double checkmark (or even blue, if Bob Charlie allows)

However, it happens only for underlivered messages. It means that an attacker capable of taking control of the user account (e.g. SIM swap) is then capable of reading all undelivered messages but not che chat history


Should I worry about an iOS rootkit? Over the course of several months, I have regularly used my iPhone's default browser for high-risk activities, namely viewing pornography. I have also failed to diligently update iOS (still running iOS 8.1 as I write this). I have not jailbroken my phone, and to date I have not encountered any symptoms actively suggesting a malware infection (such as aggressive popups injected on mundane pages, etc), but from what little I have read on iOS malware, this kind of browsing behavior coupled with outdated system software has likely rendered my device quite vulnerable to attack.

I use my phone for professional activities (communicating with coworkers, clients, etc), so these vulnerabilities are unacceptable and could result in personal embarrassment or worse if unchecked access to my texts, messaging apps, or phone client were to be obtained.

To resolve this issue, I plan to update the system OS, reset the phone to factory defaults, and set up the phone from scratch with files I have backed up to my Apple ID.

Is this process likely to remove any malware that could currently reside on the system, or is purchasing a new iDevice and Apple ID necessary to avoid a rootkit-style persistent program?

It's relatively unlikely that your phone has been infected with a persistent rootkit type malware, even if you've been viewing porn, but technically it's possible. It's also really unlikely that any malware which you had been infected with would be directly associated with your Apple ID - in general, only user generated data is preserved, while apps are pulled from the current version available on the App Store (much to the frustration of people who wanted to keep an old feature when upgrading their phone).

However, it would be possible that some malware that you had picked up now had obtained your Apple ID credentials, allowing it to access your data. In that case, you're a bit late to stop anything - could have pulled your texts/messages and be preparing to send them to co-workers now.

Your plan seems sensible, but I'd add in changing your Apple ID password, ideally from a different device, and making sure you never enter it in the current OS you're running (e.g. set the OS update running, and once that's done, but before logging in, change your Apple ID password from another device, so your fresh install only ever sees the new one). That way, assuming that your password had been compromised, but no access had been made, your data should be safe. It's probably also worth cleaning your stored data of anything you don't want associated with your account before syncing with the fresh install.

Once you're running a fresh install, make sure you regularly apply OS updates, even if they're a bit of a pain - there are good security reasons to do so, even if Apple tends to promote the new emojis as more important reasons!

Other basic advice would be to ensure that any passwords and usernames used on sites are distinct from your Apple ID ones - and from each other. It's depressingly common for accounts to be compromised following password leaks at unrelated sites, where people have used the same passwords in multiple places. If you're worried about reputational damage from pornography, don't forget that any email addresses you might have used to sign up to sites would also be exposed should a site be compromised - the biggest example of that would be the Ashley Madison breach from a couple of years ago.


Does an unused ftp account pose a security risk? I'm using BlueHost and have a few websites on my hosting. I decided to stop being lazy and start implementing some better security policies on my own part.

Since FTP isn't secure, I changed to SFTP. The odd thing is that BlueHost won't let me delete two of the FTP accounts on my BlueHost account. If these two accounts are never used, are they still a security risk?

The short, non-nuanced answer is "Yes". Even if the accounts are unused there is still a risk of brute force.

A longer answer would be "Yes, but you can greatly mitigate the risk".  I know you said you changed to SFTP, but I'm not clear if you've disabled the FTP service completely. A good chunk of the risk here can be mitigated if you're able to (or already have) harden the server by disabling FTP.

Additionally, if these users only have the ability for FTP logon you'll further reduce the risk. It's going to be difficult to exploit FTP accounts if there is no FTP service running and the accounts can only log into FTP.

I haven't run anything on Bluehost so I don't know how much control they give you over the above.


Can my ISP see documents I print trough my wireless network printer that is connected to ISP-provided router? As stated in title - I am wondering if connecting my printer to ISP-provided router could expose all of my printed data to his eyes?
Cheers!

Any device on your network may be able to monitor unencrypted traffic traveling over your local network, whether passively or actively. A router is no exception to this.
I do not imagine that this is something ISPs normally do, as it is likely to raise quite a few eyebrows. However, if your ISP is compromised or malicious, it is possible that they could install new firmware on the router that does some of these things.
So, while possible, it's unlikely. But if this is a risk you cannot afford to take, it's yet another reason to consider providing your own hardware that only you control.


Can my roommate see my web activity? I live with 4 housemates, 3 of them are software engineers and we share the internet. They use the optic fiber cable and I use my personal router, to which they don't know the password.

Could they do the following, and if so, how?

Know which websites I visit.
Read my Facebook and WeChat conversations?
Gain access to my personal web accounts (e.g LinkedIn, Facebook, StackExchange, etc.)

I am very concerned about my privacy and I think that I might be spied on.

It all depends on the technical saavy of your roommates, their desire to crack your passwords and/or find another way to log and then decipher your internet traffic, and then them taking the time to do so.

In the real world, the general answer to "can someone hack this?" is yes, it can be hacked.  What needs to be asked in tandem with that question, is what would they gain by doing so.

Your best bet in this situation, assuming there is no malice between you and your roommates, is to just be proactive in your security measures.  Use a strong pass-phrase, as a single password really doesn't cut it anymore.  Do not use the same pass-phrase for every account you use, which is a pain in the rear, but if someone breaks one password/phrase they will try it on other known accounts.

Don't use the same pass-phrase in perpetuity.  Also, turn off systems ability to save passwords/login information on websites.  If someone gains physical access to a device, worrying about what is going through the wire/wireless becomes a moot point.


How to document the Encryption or Hashing Method used in a Document? I am building a plain Text Editor that allows to encrypt, hash or sign passages.
Since I want to allow for different Methods (symm/asymm, #Bits etc.), possibly even within the same document, the actually Method used must/should be documented in the same document, preferably directly before the encrypted passage.

I wonder if there is something like a standard plain text Prefix (or Suffix) for encrypted data/signatures similar to the protocol in a URL http:// or mail:// .
The concatenated prefix and cipher (base64 encoded, also the encoding should go into the prefix) could look like this:

SHA1://XFe..ks== or
RSA512://uD4lo...df5=

You might be interested in RFC 3369, the Cryptographic Message Syntax standard.  It includes the relevant metadata which describes the information you're seeking.


Does TLS 1.0/1.1 server sign the message digest with its private key? After a TLS-enabled server generates a message digest (HMAC), does it sign the digest using the private key of an asymmetric key pair, forming a digital signature?

I'm more interested in knowing whether most of the TLS 1.0/1.1 web servers do it in production environment, rather than whether an RFC allows for it or not.

There is no signing involved when using a HMAC. The protection offered by the HMAC comes from the secret used inside the HMAC  which is derived from the master secret which itself is the result of the key exchange.
See TLS 1.0 RFC sections 6.2.3.1 and 6.3 for the details.


iMessages in iCloud feature = all unencrypted messages on Apple servers. How secure? With the presentation of iOS11 Apple introduced a new feature: "iMessages in the cloud". Now they've released iOS 11.3 beta with this feature included. I've read a lot of people are waiting for it, which means that almost everybody will use it and almost every conversation will be stored on Apple servers. Pretty scary.

According to an iOS white paper, iMessage messages are e2e encrypted, but there is absolutely no info about iMessages in iCloud. They say that messages will sync across devices, and that you can recover all messages without an iPhone backup. But how could that be, if every message was encrypted with a unique key and can be decrypted only with that key? Does that mean Apple syncs secret keys across devices?! Or does that means that Apple are going to store unencrypted messages in iCloud?

How secure is this feature?

You seem to have one of the more common misconceptions about end to end encrypted messengers. The end to end encryption is used for messages in transit from Alice to Bob, once they've reached Bob's device they're generally stored unencrypted (albeit usually with encryption at the system level). Encryption of stored messages and backups is a separate feature.

The only reference to iMessages stored in iCloud I could find in this document is the following:

  iCloud also backs up information—including device settings, app data,
  photos, and videos in the Camera Roll, and conversations in the Messages
  app—daily over Wi-Fi. iCloud secures the content by encrypting it when sent
  over the Internet, storing it in an encrypted format, and using secure tokens
  for authentication......

  Here’s what iCloud backs up:

  ...
  iMessage, text (SMS), and MMS messages (requires the SIM card that    was in use during backup)
  ...

So it appears that all data backed up to iCloud is encrypted, but the key is almost certainly held by Apple. Since the SIM card is required to restore iMessages that hopefully means that iOS encrypts iMessages with a key derived from information on the SIM card before sending the data to iCloud, but I haven't seen any confirmation of this, and I'm not familiar enough with SIM cards to know how secure this would be.

As for syncing messages without a backup, all I see is:

  The user’s outgoing message is individually encrypted for each of the receiver’s devices.

Which isn't so much "syncing" messages as automatically sending the same message to all of the recipient's devices. If the recipient activated a new device after the message was sent, it wouldn't appear on that device. This doesn't seem to line up with your claim of being able to sync and recover messages without an iCloud backup.


Does preventing consecutive characters in a password actually increase security? Sometimes I try to use a password that I can easily remember but is hard for a computer to guess. It, for example (this is not my method), might consist of 2 words, followed by a number of repeated special characters, followed by a word. This password is called "weak" by Apple and it won't let me use it 'because of consecutive characters'. It's 20 characters long and hard to guess, what makes it weak?

Preventing consecutive characters reduces security.  It's an attempt to prevent simple-to-guess passwords such as 00000000, and to prevent people from padding weak passwords up to meet minimum lengths, eg. helloooo.  However, it also prevents the use of a wide range of strong passwords.

Sticking to just eight-character lowercase passwords for simplicity of analysis, there are 208,827,064,576 possible passwords.  Approximately 56,000,000,000 of those passwords contain consecutive identical characters, so in an attempt to prevent the use of weak passwords, you've reduced the complexity of a brute-force attack by about a quarter.


Understanding SSL certificates How does an SSL certificate prove the emitter is who he pretends to be ?

If Bob (holding a certificate) and Alice wanted to establish a SSL-secured connection, wouldn't John be able to get the certificate from Bob and send it to Alice, pretending to be Bob ?

I understand the private/public key very well, but I don't understand what role it plays in a certificate.

In order do pretend he's Bob, John will not only have to present Bob's certificate, but also prove that he is in possession of the private key corresponding to the public key in said certificate, by encrypting a challenge with it. So copying the certificate alone will not buy John anything.


What's the relation between a Security Framework & Standards, Guidelines, Procedures and Policies? I'm currently writing a paper about security standards. Therefore several terms have to be defined before I can actually start. The problem is that in every resource the term "Framework" is somehow connected to the terms "Standard", "Guideline", "Procedure" and "Policy". However, I fail to find a general definition for the term, since every resource defines it in a different way. E.g

"A Framework is an assembly of standards, guidelines and best practices, which helps organizations at managing their assets and reaching their goals"
"An information security framework is a series of documented processes that are used to define policies and procedures around the implementation and ongoing management of information security controls in an enterprise environment"
"A Framework is a general guideline that an organization can adopt."
"A framework is at best, a frame that can be used as a practice."

etc..
So, obviously people have completely different definitions for a framework. But which one is correct? Any experts here that can give me a short explanation?

I will reiterate my comment above so that this question has an answer. It appears to me that the confusion arises from how broad the term "framework" is. I believe the exact term you are after is "policy framework".

  A policy framework is document that sets out a set of procedures or goals, which might be used in negotiation or decision-making to guide a more detailed set of policies, or to guide ongoing maintenance of an organization's policies. A framework might be used by a large organization such as a company, educational institution, or government, to inform employees about whose approval is needed to make new policies, what rules new policies must follow, how policies should be communicated and enforced, and what high-level or long-term goals that new policies should try to support.


How does client-side cookie encryption enhance browser security? If cookies are stored in plaintext, then any program which has read access to the cookie file can hijack the browser session, which is bad. However, even if cookies are encrypted, the browser must have enough information to decrypt to actually use them. It doesn't look like the browser fetches that information from remote every time it wants to decrypt a cookie? But if that information is stored locally, then any program having access to it can decrypt the cookie as well. How is cookie encryption helpful in this case?

Edit: This question is not about server-side cookie encryption. See this commit for background.

After your edit, the question is about something entirely different.

That commit is about encrypting the cookie database with an user-specific key, for Windows' users. On a multi-user Windows environment, it's common for a user to have access to other users' files. Encrypting the cookie database with a key held on the user registry and derived from user password, other users cannot access that data.

This increases cookie security, because any attacker getting the database file will not be able to read the cookies. To read the data, the attacker must get the computer while the user is still logged in, or compromise the password.

But the cookie database is not as valuable as the saved password storage.


Dangers of client & server package, communication over HTTPS using user's own self-signed certificate? I want to create a client & server package with the option of an encrypted connection.

From my limited understanding, to get HTTPS connections working, the user needs their own certificate installed on their machine and this means that the client software needs to allow all certificates (with a user-specified public key/thumbprint?).

I'm new to the concept of certificates so I don't know about any of the associated dangers here. Could you please briefly list some problems with this approach?

To enable your clients to securely communicate with your server, you will need an SSL certificate for your server that is either self-generated or signed by known certificate authority.  If you go with self-signed you will need to provide the public key of that certificate along with your software.

If you want to identify your clients, they will each need a unique client certificate probably signed by your CA.

Short version:

Secure client/server communication - server certificate
Secure client/server communication with authenticated clients - server and client certificates

It sounds to me like you should pull in an expert for this part of your project.  Crypto is easy to get wrong and important to get right.


What is an active attack? Browsing through the site I encountered this Is there a way to negotiate a secret between 2 parties with no prior knowledge?

What is an active attack then?

An active attack is one where the attacker modifies network packets while they are in transit, or sends forged network packets.

A passive attack is one where the attacker merely eavesdrops on packets that others are sending, without injecting any new packets and without modifying any of the packets others have sent.

This should be covered in any cryptography textbook.


How could you safeguard your data traces when using USB Drive? I have a very serious question with regard to data security with regard to usage of USB Drive when transmitting, storing or even clearing data with it.

When one is going to use USB Drive for interacting with critical data, how could maximise the absolute security of the data so that the data is extremely protected when using a USB Drive?

My questions include:

When you try to store data on a USB Drive, how to encrypt the drive so good that nobody else can gain access into the data except you? Or if they do, the data would get automatically destroyed?
When opening the data with that USB drive on any computer, how to make sure it won’t leave any trances of the data on that computer after the USB Drive has been ejected? So no one could indirectly get the traces of data when scanning the relevant computer being used?
When you want to delete/erase any data on the USB Drive, you want to erase it completely on the USB alone without allowing the computer you are operating on to leave any traces on its own Recycle Bin....so what you can do to erase any data on a USB drive independently and permanently without leaving traces behind?
When you want to dispose a USB drive completely, you might have had all the traces of past/deleted data still left in the memory part of device, how could you overwrite the USB Drive properly or you’ll have to physically throw it into a volcano to make the safe disposal job done properly?

Sorry, I want to know the best way to make data secure while using USB Drive. (Cloud might not a safe place to store your data as it connects to World Wide Web at the end of the day)

Many thanks!

Strongly encrypt it to AES-128 or stronger. I like the ones with physical keys, like the iStorage; they are self contained and you can't mess up installing the software.
It you can't trust the computer, boot from the USB so it's only running your software. (Of course you can't trust the hardware either...)
See 2 and 4.
Simply throw away the encryption key to effectively wipe the stick. (But throw it in the volcano anyway, just in case.)


CVE-2016-6662 + MySQL 5.5.52 According to different Websites MySQL 5.5.52 [1] [2] is affected by CVE-2016-6662.

At the MySQL 5.5.52 Release Notes i see that the security problem should got fixed in the 5.5.52 release:

  For mysqld_safe, the argument to --malloc-lib now must be one of the directories /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu, or /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and --mysqld-version options can be used only on the command line and not in an option file. (Bug #24464380)

I am unsure if i am affected or not, the exact installed version on my server, which is running on CentOS 6, is mysql-5.5.52-36.el6.art.x86_64 from the webtatic repo.

The paper on legalhackers.com from Dawid Golunski, which had found that issue, does not list my mysql version.

FWIW, the Oracle Critical Patch Update release notes agree with the CVE descriptions, 5.5.52 is affected.

As to the legalhacker link, considering that he published that six days after 5.5.52 was released I'd guess that he never tested that version.


Multiple SSL certificates on load balancer We are discussing with our Operations department about wildcard SSL certificates.
Our purpose is to forbid all wildcard certificate (like *.domain.com) for internet exposed web application because of their potential security risks at least in the production environment.

Not taking in consideration the costs associated to the purchase of certificates (one per web application) they claim that the solution is not feasible because all SSL certificates are managed on the load balancer.

I have no experience in managing load balancer; I suppose that it's like an Apache configuration with more than one virtual host, each virtual host with its certificate (i.e. https://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm).
A recent news from Akamai says that SNI is widely adopted (https://blogs.akamai.com/2017/03/reaching-toward-universal-tls-sni.html).

What are the real difficulties in managing many certificates on a load balancer?

Is there some best practices from authoritative source?

Not taking in consideration the costs associated to the purchase of certificates (one per web application) they claim that the solution is not feasible because all SSL certificates are managed on the load balancer.

Arguably this is a Server Fault question as it's asking about configuration of a load balancer.  It's impossible for us to answer completely because we don't know what setup your company is using.  However, generally speaking adding additional certificates should not be difficult; it should be only a few lines of configuration, and the operations folks should have configuration management scripts that allow them to just add another cert into an array and let the tools generate the resulting config.

However, a much more common approach is to use a SAN cert that contains entries for all of the domain names you're expecting to use.  Take a look at the certificate here, for instance:

This is also commonly used by CDNs so that they don't need to manage a whole bunch of certificates from each of their clients:

The key problem here of course is that you need to renew the certificate when adding a new domain.  To combat this, I would require advance notice that you want to add a new domain, and batch a bunch of them together into a new cert; so if you renew certs every year and add new domains monthly, you'd have twelve certs installed on the load balancer, one for each month.


What protections are put in place to prevent ACH scams? ACH (Automated Clearing House) is an electronic network for financial
  transactions in the United States.

ACH is used by financial institutions to handle direct deposits, checks, bill payments and cash transfers between businesses and individuals. According to several sources online, to pull off an attack. All you need is an account number and a bank routing number.

What protections are in place to protect banks and consumers during ACH transactions?

What type of exploits are currently being leveraged against ACH transactions?

Currently, the only way to protect against ACH are detective controls which should be in place at the business and the bank. Most fraud gets detected after accounts get reconciled or after a customer complains that his account was used without authorization. In case of a bank, if a company only uses it for payroll payments and those payments occur once a month, transactions occuring outside the normal period should be looked into.

Consumers need to alert their institution within 60 days in order to recover funds. Businesses, however, only have as little as one business day. Therefore, monitoring becomes critical. Daily review of the credits and debits of the business is essential in detecting fraudulent activity.

Companies using ACH set up accounts that would either only accept ACH credits or issue them. As ACH expanded past the payroll, social security payment or repetitive bill-pay solution, moving into mainstream transactions, the direct relations were lost between the two parties and this opened a gate for fraud.

Common fraud schemes against the banks include setting up fake companies, getting on the ACH network, issuing lots of transactions to a single account and then emptying that account, leaving the bank behind with the losses. This is called ACH kiting.

Then there's also typical fraud where an attacker gets access to a company's network and just adds transactions in the transaction  file or just executes transactions on behalf of the company.

Note that ACH was never designed to fullfil the task it's currently used for.


Should I be using ECDSA keys instead of RSA? I read on ssh.com that there are new ECDSA ssh keys that one should be using to create the public / private key pair; and that's it's a US Government Standard based on elliptical curves (probably something mathy).  I also noticed that they use fewer bits, so I'm unsure how it is supposed to be more secure.  Have you heard anything about this, and if it uses fewer bits how on earth could it be more secure?

For "bits of security", see something like this comparison.

For why ECC over Prime Field gives you security equivalent to half the bit size, while RSA and FFDHE give much less security per-bit, it's because the strength of RSA against the best known attack is calculated like this while the strength of ECC against best known attack is calculated like this.

The NIST P-256/384/521 curves are safe, and ECDH over them and the ECDSA algorithm are safe, but they are a previous generation of curves and algorithms. The advancement since then has been in three areas:

Choosing a curve in a non-arbitrary way so that it is much more "nothing up my sleeve", to ensure the curve isn't one in which the NSA have a way to break crypto faster than brute force, which people worry about. You shouldn't worry IMO, for these reasons, but some people consider it a reason to upgrade from NIST curves.
Ease of implementation, or equivalently, chance of a random implementation turning out to be secure.
Performance.

The state of the art currently and the ECC systems recommended by everyone is X25519 ECDH (Curve25519 ECDH) and Ed25519 Digital Signatures / long term keys. Basically everyone agrees they are better than NIST P-256 ECDH and ECDSA. A drawback is that they are not supported in HSMs and hardware tokens like Yubikeys.

If you can use software SSH host keys, you should use Ed25519 host keys.

If you can use software SSH user keys, you should use Ed25519 user keys.

If you can use curve25519 key exchange, you should use it.

The fallback for 25519 is NISP P-256. The fallback for P-256 is RSA and FFDHE, with at least 2048 bits (up to 4096 bits), both with SHA2 and not with SHA1. RSA with SHA1 and FFDHE with SHA1 are not allowed anymore.

Note that all of these systems will fall if and when someone builds a big enough quantum computer. To solve this problem, people are working on "post quantum" replacements that will be secure even if the adversary has a quantum computer. NIST is waiting for PQ Crypto competition to end, issue recommendations and standards, hardware crypto device vendors to start selling PQ devices, and everyone will upgrade to the PQ algos.

Because this upgrade is imminent (in NIST time frames), they have decided to not urge everyone to upgrade from P-256 to Curve25519, or even from RSA to ECC. NSA basically said to save your budget for the PQ upgrade.

People using SSH keys not stored in hardware devices have upgraded though, and everyone has upgraded ECDH because ephemeral keys don't need hardware secure storage.

Even the ossified TLS ecosystem (not SSH) has upgraded to X25519 ECDH, though they can't upgrade to Ed25519 because there are no HSMs available and they basically decided to wait for PQ crypto standards and HSMs. The standards / RFCs are available, it's just nobody uses them.


How do browsers know which cookie to get? I tried writing a script that would display the contents of a cookie set by another website but it didn't work.

<?php
 echo 'Website cookie is  '.$_COOKIE['locale'];
?>

But I get an undefined index error. Can cookies only be retrieved by the issuing site? I've got the add on Cookie Manager in Firefox opened and each cookie has a site and name. So can a cookie only be viewed if the site requesting it also issued it and (obviously) the right name is given? How is the enforced - are web browsers simply programmed this way or do the cookies have some sort of inbuilt security?

Yes, browsers enforce cookie domain scoping.   There are a number of rules around when cookies may be sent, but the most basic rule is that cookies are only attached to requests to the same domain from whence they were set.

Additionally, if the cookie has a path attribute it will only be sent with requests that match that path within requests to domain from which they were set, and cookies that are marked with the "secure" flag will only be sent along with requests that are made via HTTPS.


Requirement to send username and password in distinct email messages I have an application that sends username and a password by email (random temporary password, mandatory change on first login).

A big customer has this policy of "never send username and password in the same message" - and they are demanding a change in order to split it in two email messages, one containing the username and other with the password.

I would understand if the demand was to send information using distinct channels, lets say, send the username by email and password by SMS, because compromising both channels is harder. But sending the information splitted in two messages over the same channel makes no sense for me: if you think your email can be compromised, you must assume the attacker will be able to read both messages, so what is the fracking point?

Is there any logic behind this policy?

I would characterize this security recommendation as Cargo Cult Security.  I don't know of an exploit that only compromises a single email.  There isn't a weakest link that is being removed by sending this in two emails,  its just annoying as hell to users.

A temporary password or token passed as a GET parameter is commonly sent via email.  I have never seen this process broken into two emails.

I would ask the security analyst that recommended this change to give you a specific scenario in which this improves security.


What are those http://123.249.24.233/POST_ip_port.php POST requests I get on my server? I receive a lot of requests on my Node.js server, which I don't understand.

On the picture, there are phpMyAdmin-oriented requests, that I understand as automated testing against phpMyAdmin.

But I also have testproxy.php and http://123.249.24.233/POST_ip_port.php requests on distant servers that I can't understand. Does anyone has an explanation ?

It's a malicious bot, that is trying to scan web application for security vulnerabilities.

Look at these links for more information about blocking it:

https://serverfault.com/questions/700404/huge-traffic-from-post-123-249-24-233-post-ip-port-php

https://gist.github.com/renancouto/0ad35842f1c536c1dbbe


How can I exploit a XSS vulnerability which doesn't allow me to type  symbols and puts my input in double quotes? I have the following script:

function filter() {
    const inputstring = JSON.stringify(document.getElementById('input').value)
        .replace(/[<]/g, '%lt')
        .replace(/[>]/g, '%gt');
    const userTemplate = '<script>let a = %userData%</script>';
    document.write(userTemplate.replace(/%userData%/, inputstring));
}

First of all, it reads the string submitted with the help of HTML input. Then, it analyzes the string for the < and > symbols. If they are found, they get replaced. Then, it replaces %userData% with our input and writes it.

How can I bypass this filter and exploit XSS here? The line <script>let a = %userData%</script> looks quite interesting as it already contains a script tag and a variable a. It is also quite pointless to use > and < symbols in input, so I guess we are forced to use the variable a. The problem is that all my input gets surrounded by double quotes (the result is <script>let some = "text"</script> when my input is text), so I can not execute any functions. Maybe it is somehow possible to get rid of the quotation marks?

Yes, this filter can be bypassed by playing around with special replacement patterns.

$'$`alert(1)//

The output of the payload above will look like something along these lines:

</script><script>let a = "</script><script>let a = alert(1)//"</script>

If you are interested in learning more about similar bypass techniques, I highly recommend giving http://prompt.ml/ a go.


TLS Session Tickets: What is the risk of a disclosed server ticket key? So there is this TLS Session resumption method using Session Tickets which transfers the TLS server secret state to the client (encrypted and authenticated with a key only known to the server)

If a client wants to resume a session, he simply includes the Session Ticket in the request, which allows the server to resume the session.

Questions:

What happens if the Session key (server) is stolen?
What could an attacker do if he records ALL packets between the server and various clients? Will he be able to decrypt everything?

The Session Ticket includes the master_secret (which is used for symmetric crypto like AES?) (RFC 5077, page 11).

How exactly is this master_secret reused after Session resumption?
Will server and client continue to reuse this master_secret for all symmetric crypto (e.g. AES)?

Ticket crypto broken -> PFS broken.
I believe this quote from a great CloudFlare blog post answers each of your questions.

Zi Lin, CloudFlare, Inc., 2015-02-24, TLS Session Resumption: Full-speed and Secure

this key becomes [a] critical single point of failure for TLS security: if an adversary gets hold of it, the session key information is exposed for every session ticket! Even after the lifetime of a session ticket, such a loss would invalidate supposed “perfect forward secrecy” (as evangelized here on our blog).
Therefore, it is important to:
“generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.” (Adam Langley)

And they link to a blog post by Adam Langley that gives background for this:

Adam Langley, 2013-06-27, How to botch TLS forward secrecy


Shortest SHA-3 output I noticed in the new SHA-3 standard that it has a variable output size. Knowing that longer output is obviously better (higher entropy), what is theoretical the lower limit of the output size? Can my hashed output, e.g. be 8 bits long? I know for most scenarios this would not be secure.

You have a misconception:
With SHA3/Keccak, being a bit strange compared to previous hash functions, output size is not comparable to security. A certain security level requires a minimum output size, but the output can be made longer without increasing the security as hash.

The minimum hash size (of Keccak in general, not of the standardized subset called SHA3) is 1 bit:

In the sponge construction the value of the sum c+r is restricted, but how much of it is c and how much r is freely choosable. Make r=1 and do only one iteration in the squeezing part (after the vertical line), then the hash output z0 has exactly 1 bit.


Is a 43 character GPG (symmetric) passphrase as secure as a 256-bit key? A 43 character securely randomly generated mixed case alphanumeric password (with 2 extra chars to give 64 possibilities per character) would constitute 258 bits of entropy (6 * 43 = 258).

Since the gold standard in AES symmetric key lengths is 256 bits, am I right in concluding that GPG will use my 43 character securely randomly generated password to create an encrypted file that is just as secure as if I'd used a securely randomly generated 256 bit binary key directly (instead of deriving it from a passphrase)?

I'm looking for gotchas, such as whether despite specifying to the gpg command to use AES256, maybe the KDF will still only create a 128 bit key from my 258 bits of entropy?

Thanks

There is in fact no difference in security between a 128-bit symmetric key and a 256-bit symmetric key. The reason is that security against brute force is relative to the technological means available to the attacker, and there is no way that the technology in the foreseeable future will allow a 128-bit exhaustive search to be performed with non-negligible chances of success.

By "foreseeable" here, I mean "within the next 30 years". Anybody who claims to be able to predict technological advances for longer times is either a time traveller or a filthy liar. Note in particular that it I claim that there will not be, in the next 30 years, a quantum computer that is large enough to run key tests on 128-bit AES and can do so for 264 steps -- the latter condition being very non-trivial. It is of course conceptually possible that mathematical advances will be found, that would simplify exhaustive search, but this is highly speculative and there is no real indication that a 256-bit AES key would resist such things better than a 128-bit AES key (in fact there are some esoteric attacks, called "related-key attacks", which fortunately do not apply to practical cases, and for which AES-256 is weaker than AES-128).

Since there is nothing stronger than non-breakable, one can say that AES-128 and AES-256 are equally good for security. We may even say that AES-128 is slightly preferable, since it is slightly faster (but it won't matter much).

That being said, in OpenPGP format, passphrases are turned into keys through a string-to-key transform. The recommended one (the "iterated and salted" transform) hashes a long concatenation of multiple repetitions of the passphrase and the salt. The total size of that which is hashed is configurable, but the point is that each passphrase try should cost a lot. This mechanically increases resistance to exhaustive search. For instance, if the iteration count is such that a passphrase-to-key transform costs as much as about one million AES invocations, then you only need 108 bits of entropy in the passphrase to reach 128-bit equivalent security. Of course, increased cost is increased cost: you do not get extra security for free.

The iterated-and-salted S2K uses an inner hash function which could be SHA-1 or even MD5, but it is not needy with regards to the cryptographic robustness of that underlying hash function. Even if it is the very broken MD5, and even so MD5 output is only 128 bits, the iterated-and-salted S2K is defined in such a way that it can still keep about all your passphrase entropy in the resulting key. Thus, if you have 256 bits or more of entropy in the S2K input (the passphrase), and you want a 256-bit output key, then that output key will have at least 255 bits of entropy.

(If you have exactly 256 bits of entropy in the input, you expect a theoretical 255.34 bits of entropy in the output.)

To sum up: there is no "gotcha" in the way the passphrase is turned into an encryption key, but even if there was, you would still get a security level that is not different, in any practical meaning of the term, to the theoretical "256-bit" level.


Do we need to maintain Authentication and Authorization Logic separately? We are using Keycloak Identity server which will take care of Authentication and Authorization for our new Multi Level Marketing Website.

There was a discussion going on within our team to maintain Authorization concepts separately in our local database. As we need to use ID server only for Authentication it seems.

What are the best practices to maintain Authorization and Authentication logic separately?

Do we need to maintain Authentication and Authorization Logic separately?

Yes, yes, yes!

These are two different tasks.  Conflating the two incorrectly is one of the most common sources of vulnerability.

Number 2 and 4 of the OWASP top 10 this year, specifically:
https://www.owasp.org/index.php/Top_10_2017-Top_10

Authentication is "who are you" and authorization is "what can you do."

Authenticating a user does not authorize them, and being authorized is no guarantee of authentication.


How to prevent malicious movie uploads? I am creating a movie upload site, and I am wondering how I would verify that the movie I am uploading is in fact a movie.  I know that getimagesize() will test images, so is there an equivalent of this for movies?

PS I am using Apache2 and PHP

Using getimagesize() is not made for testing if the file is an image. Just determining the type of known valid images. It is not meant for security, and can only be used as an extra check. A malicious file might make the function return a valid value while still being malicious, so that's no good.

OWASP is the go-to source for prevention and attack cheat sheets. This is the main point on file uploads:

  The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.

  "crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".

  ".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted.

https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Upload_Validation

More can be found here under prevention:

https://www.owasp.org/index.php/Unrestricted_File_Upload

But even this will fail if there's a vulnerability in the parsing code of your application ( stagefright for example )


What (besides not complying, and reporting) should I do with blackmail emails? I received the following email which claims, among other social engineering, to have installed a keylogger on a former system administrator's Linux box:

  I know [old password deleted] one of your passphrases. Lets get directly to the purpose. No-one has paid me to check about you. You may not know me and you are probably thinking why you're getting this mail?

  Well, i actually placed a software on the 18+ vids (pornographic material) website and guess what, you visited this site to experience fun (you know what i mean). When you were watching video clips, your web browser initiated functioning as a Remote control Desktop that has a keylogger which provided me with access to your display screen and also webcam. Just after that, my software program collected all your contacts from your Messenger, social networks, and emailaccount. after that i made a video. 1st part displays the video you were viewing (you have a nice taste haha), and second part displays the recording of your web cam, & it is you.

  You will have not one but two choices. Lets check out each of these solutions in details:

  First choice is to neglect this email message. Then, i am going to send your very own recorded material to each of your your personal contacts and thus just think concerning the shame you feel. Furthermore if you are in a romance, how it is going to affect?

  Latter alternative is to pay me $7000. Lets think of it as a donation. Subsequently, i most certainly will asap erase your video footage. You could keep going daily life like this never happened and you are never going to hear back again from me.

  You'll make the payment through Bitcoin (if you don't know this, search 'how to buy bitcoin' in Google search engine).

  BTC address: 1EWaFmaMG33BB6pujkcJUFsp5PxLbQVnhw
  [CaSe-SeNSiTiVe copy & paste it]

  if you are curious about going to the law, okay, this message cannot be traced back to me. I have covered my moves. i am also not trying to charge a fee so much, i prefer to be rewarded. i have a specific pixel in this email message, and right now i know that you have read through this message. You have one day in order to make the payment. if i do not receive the BitCoins, i will certainly send your video to all of your contacts including members of your family, colleagues, and so on. Having said that, if i do get paid, i will erase the recording right away. if you want evidence, reply with Yes then i will send your video recording to your 7 contacts. it is a non:negotiable offer, thus do not waste my personal time & yours by responding to this email.

I know the standard response to ordinary spam, and the ordinary response to phishing. I reported this as phishing because it seemed a closest fit, and furthermore far more severe than "BETH ADD REAL INCHES TO YOUR PEN1S!".

How can I, or should I, respond to blackmail spam? Is any LE followup appropriate?

The only important takeaway to this particular scam is: change the password.

This scam has been around since approximately July 2018 and so far there are have been no videos published (that are linked to this type of extortion) but a lot of money has changed hands. One source claimed that "So far, 30 victims have paid more than $50,000 in total". One thing that we do know, that the password that is sent is indeed real. The scammers probably did not get this by penetrating your machine, but by copying it from a database of leaked credentials that are found in shady forums.

TL;DR:

Change your password. Don't reuse passwords. You can also check haveibeenpwned.com to see where and when your credentials were leaked.


Can a certification authority sign another CA's certs? Disclaimer: I have low knowledge of X.509 and PKI, so I would appreciate an answer that is not entirely technical, i.e. by using real-life example scenarios.)

I was searching for information about 4096-bit TLS certificates, found an article talking about it and how you could generate a self-signed certificate.

  Signing your own key.

openssl x509 -req -days 730 -in my.csr -signkey my.key -out my.crt

  Signing your key will save you the few bucks a year a CA will charge you, but it will not be recognized by others unless they import your certificate.

The not recognized by others part left me wondering. To me, X.509/PKI works a bit like OpenPGP: it has asymmetric cryptography, trust is built with certifications, etc.

Let's take a widely-trusted CA, for instance VeriSign. If signing a certificate asserts trust (= the root VeriSign cert signs the intermediate VeriSign cert, the latter becoming trusted too), then I have the following question:

Is it possible that a CA (like VeriSign) make another CA trusted (so that, for example, a CAcert-issued certificate would become valid and recognized in browsers, just by VeriSign signing the root/intermediate certificate of CAcert)?

Would that even work with self-signed certificates? Or do I wrongly understand X.509 and CAs cannot interact with each other?

Yes, it is possible, but the better question is would they?  The CA's reputation is their life blood.  Why would they give a trusted signing authority to another CA that might not hold up to their standards (and could be a direct competitor in the future.)  To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would consider doing so in the future.  Apparently some CAs do allow this, but they have extensive requirements for the security of the sub certificate and charge a very large amount for the privilege.


Risks of deploying a server authentication certificate along with a client application What are the risks of deploying a client application with server authentication certificate (private + public key) so that a client application can host a webserver. Which is accessible via HOSTS redirect through the browsers.

What are the risks with the following approach?

Assume

I own the "example.com" domain.
I get a valid server authentication certificate for "app.example.com", say for e.g. from Comodo.
I have a web application hosted at "https://www.example.com".
Users are supposed to do some action which requires me to send some requests to an application running on their system and get a response.
I do this by installing a client application on user's system.
This application has the server authentication certificate for "app.example.com" issued above. It can host a locally accessible web server.
During installation, I add an entry to C:\Windows\System32\drivers\etc\hosts for a redirect from "app.example.com" to "127.0.0.1"
When user is using the Web application at "https://www.example.com" it also connects to "https://app.example.com" which is actually the client application running on users system.
Browser can send requests to an application running on their system and get a response.

Things I would like to know: Risks, Fixes, Alternative Approaches etc.

Update: Additional Question:  Certificates for localhost, MITM Attack

I preparing a list for why not to do this as asked in the question. As well as for my understanding.

You are publishing a certificate for https://app.example.com along your app. Thus this private key is no longer "private". Someone will find out and publish it. This will lead to the CA revoking your certificate for app.example.com (they MUST revoke it). This has happened in the past, you are not the first one to have such idea, companies like Cisco, Blizzard, EA, Spotify, mega… used to do this.

This is more a procedural issue, but it will bite you quite quickly (do remember that the CA have 24h to revoke it once they are made aware that the certificate is compromised).

A MITM could extract the certificate from your app and impersonate app.example.com on someone which don't have the hosts entry, but it isn't worth listing the risks with that given that your approach won't work for too long.

If you really need to use a certificate for https://app.example.com, create a certificate locally (so that each client have a different certificate), properly constrained, and add it to the client certificate store.

Plus, obviously, the server running in the client shouldn't do silly things such as allowing launching arbitrary programs, or exfiltrating client files. That local server is a security boundary, so it shall be very careful validating any input…


Committing encrypted passwords but not usernames I’m arguing with a colleague about the security of storing encrypted password on GitHub.

Our process is currently to commit a configuration file with environment variables including username and passwords. Username and passwords are opaque information in the file. They are then read by third party server who has the key to read it.

First of all, since the server is able to decrypt the password, it’s clear how this discussion might be irrelevant if we don’t trust the security of the server.

I would like to focus only on the particular file, assuming that the server is impenetrable.

My opinion is that the file should be commented to identify the various passwords and what their purpose is. Also I would leave usernames in clear text. This will make it slightly easier to maintain the file and update the relevant field if necessary. Without these pointers the configuration file looks like a wall of identical lines, each with opaque informations.

My colleague argues that this might give a hint to a hypothetical attacker.

Let’s leave aside the fact that if an attacker has access to our private repositories those passwords are the least of our problems.

Do you think that commenting the file gives away too much information or that it might make it easier to have a security hole?

You should never be committing secrets to source code of any kind, encrypted or not. The username to authenticate into your server is probably a bit much in terms if sensitivity on its own, let alone a password even if it is encrypted. (As an aside, it sounds  like you’re storing your password insecurely - more on that below.)

I would highly recommend integrating instead with a secret storage system.

This is for a few reasons. First and foremost, source code can get lost. You can make the repo public accidentally, an attacker can get access to it while private, you can accidentally give the wrong person access, etc. - and the beauty of version control is that it’s a permanent record, so as long as a secret is in your version history once, it’s there forever.

Furthermore, humans are exceptionally bad at managing information - bad enough to need an entire highly skilled industry on simply information security - and very very prone to making mistakes. So as long as a human can touch it, and mess it up, and possibly steal it, it’s wise to build as though they will. The solution then is to reduce the number of humans who have access to the tasty treats, and the best way to do that is to automate it.

Also, you may want to reconsider how you’re protecting your passwords. Although private key encryption is strong and AES-256 is, of course, quite cryptographically secure, hashing and salting passwords is generally better practice. Aside from being more performant, you never want to be able to decrypt a password like this (because if you can do it, then the decryption key can get lost and someone else can now do it too). Salting and hashing (using a standard library like bcrypt, scrypt, PBKDF2, etc.) is better practice.

Finally, passwords are scary and this sort of thing matters. Please keep in mind this is only general information, varies by system, and might be entirely wrong if applied to your situation. So take this information with a grain of salt and skepticism and don’t make any decisions off of it.

Good luck!


decrypt the code in portuguese A friend of mine sent me this encrypted message and I have no idea how to decrypt it!
And btw, to make things worse, the message is in portuguese, not english!!
Here:
V2tod1lXTnNiM2xUYWxaU1ltNUNhRlpxU2xKbFJteFhXWHBHVGxKdVFsVlZWekUwWVRGVmQxTlla
RmhXYldob1dWVldjMU5HV25WagpSM0JUVFZadk1WWXhXbXBOVjBWNVUycFdVZ3BpYlZKaFZqQldk
Mkl4VGxaYVIwWm9VakJ3U1ZWdE5YTk5kM0JQWVRGYWRWZFVRbXRXCk1sWjBWRmhzVUZZeWFIQlZi
bkJIWXpGc2RFNVdUbWxSV0VKTFZXNXdSMkl4YTNwaVJVNXBDbEl4U2xWVlZ6RnZWMnN4ZEdGRVNs
UlcKVjJoSVZGWmFkMVpHUm5WV2FrNVBZWHBWZVZVeFZtOVpWMFpJVW14U1VtSllVbWhEYkdSR1Rs
aEdXazFxUm5wYVJFcFRVMFU1V0U1WApjR2tLVmxad01GWXhXbTlUYkc5NVVteHNWV0p1UW5CYVZs
WkxZekZzZEU1V1ZsTlNlbWcxVkRCb1YxTnNTbGRYV0doRVlUSjRTbFZ0CmNFZFpWbVJHWTBoa1dG
WnJOVVJaYkZwelYwZFdTQXBoUjI5TFdWWldTMDVHY0VkYVJscGhUVmhDV2xaSE5YZFpWbFYzVTFo
a1dHSkgKVGpSYVJFcExUbFpHY1ZGdGJFNWlSVzk1VlRGV2ExWXdNVlppUldocVlURktNbFpVUWtw
a01XUlhDbUZIUm1oU1YzaEpWMnRvWVdGcgpNSGhUYlRsYVlsUkdWRnBIZEhOVFFYQldZbGhrVEZV
eFZtOVpWMUp6WVhwU1ZVMHdXa3RWYWtaM1lqRndXR0pGVGs1U2JrSlpWRlpvCmEyRlhWbFlLVTI1
T1dtSlVWbFpWYTJNMFpWVTVTRnBIY0ZoU2JIQjZWMVJKZUdNeVJrWmlSV3hXWWxob1MxVXdWa3Rq
TVdSeVdraE8KYkZaWGVFbERiRnAxVld0d1UyVnNXblpYVjNocVRsZFdXQXBUYWxaU1ltNUJlbFJx
UVhoaWJHUnpZVVU1YTJRelFtaFdNRlozWWpGdwpTRTFWV21GTmExcGFWa2MxZDJGWFZsWlRhazVZ
WWtkb1VGcFhNVXBsVmtwMVZHMXNWMDFXYjNoWGExWnJDbFpzYjNsVGJHZExWVzAxCmQxTnNUa2Rq
UkVwWVZrZG9VVmt4Vm5OVFJUUjNWVzVhVG1GdGFIVlhhMk40VWpKT1JtSkZhRlppV0doeFZGZHpN
VTVXYkZkaFJVNU8KVWpCc05WZHJhSE1LVjJ4WmVHTkhPVVJpVlRWM1ZWYzFRMkZyTUhkT1ZFcFVW
bGRTV0ZwR1pGTlVaM0JWVFc1Q2NGcFdWa3BrTWxJMgpWMnRhWVUxc1NrcFZNakZ2WVZkS2NsZFlh
RnBXYlZFd1drZGtkZ3BRVVc4OUNnPT0K

It looks like it is encrypted using XOR encryption, with the key: 0x123f48233c3b2b150d5d097405097a30381e546240. When I decrypt the first few bytes of your message using that key, I get
ET Telefone de casa!!
I'm not sure what that means in Portuguese... But, here is what I did to decrypt the message:
First, convert the first few bytes of the message from base64 to hex:
echo -n 'V2tod1lXTnNiM2xUYWxaU1ltNUNh' | base64 -d | xxd -p

This produces:
576b687759574e7362336c54616c5a53596d354361

Now, use python to XOR this with the key 0x123f48233c3b2b150d5d097405097a30381e546240:
python3 -c "print (hex(0x576b687759574e7362336c54616c5a53596d354361 ^ 0x123f48233c3b2b150d5d097405097a30381e546240))"

This produces:
0x45542054656c65666f6e6520646520636173612121
Now, convert this hex to bytes, and ascii-decode the bytes:
echo -n '45542054656c65666f6e6520646520636173612121' | xxd -r -p

This produces:
ET Telefone de casa!!

By any chance, are you expecting a call from a famous 80's movie alien?


The impact of the Sony attacks on the security industry First of all there was the PSN hack, which was compromised due to a vulnerable version of Apache and no Firewall and using a developer console. Then Sony Greece fell due to an SQL Injection attack. Then there was a phishing site on Sony's Thailand servers. Then Sony Canada and Sony Japan were compromised. Then today SonyPictures.com was compromised.

How significant is itfor such a large corporation to be continuously attacked like Sony have been and what if any impact will these attacks have on the IT Security industry?

Jan 2, 2011
GeoHot releases Root Signing key for the PS3.

Febuary 16,  Bret (Trixter) McDanel pokes around in the PSN trying to reverse engineer connection protocols and chat protocols. Essentially breaking the trust model of PSN by issuing a self signed cert and bouncing off a proxy he controlled.
http://173.255.232.215/logs/efnet/ps3dev/2011-02-16
(Wired Details some of that)
http://www.wired.com/threatlevel/2011/04/trixter/

Rebug Released Late March (3.55.1) allowed access to the Dev-PSN using the RootKey
http://attackofthefanboy.com/news/playstation-3-hackers-using-developer-network-to-access-psn/

SOE Fires 205 Employees the same day Rebug 3.55.1 is released.

DDOS Performed against Sony by Anonymous for filing Suit against GeoHot.  Claims by many, including Sony, was this was used as a great distraction by the malicious attacker.
http://www.eweek.com/c/a/Security/Sony-Data-Breach-Was-Camouflaged-by-Anonymous-DDoS-Attack-807651/

PSN goes offline April 20th.

a Week later, Sony says  happened.

They announce:
April 26th
PSN and Qrocity data exposure (77 Million Customer Records including 10 million Credit Card numbers)
http://www.h-online.com/security/news/item/PSN-hack-Personal-data-of-millions-of-customers-stolen-1233209.html

SOE Announces "No Breach Has occured"

Days later, SOE announces, we're sorry our bad, 24.6 million accounts were actually compromised.
http://www.geekosystem.com/sony-online-entertainment-hacked/

Lots more came after that:
So-Net, Sony Greece, Sony Erikson Canada, Sony Thailand, Sony Music Japan, Sony Music Indonesia, Sony Pictures


Is Bluetooth a secure protocol? I constantly get bluetooth patches in Windows 10.

However I see no new features, bluetooth is just bluetooth, how many possible patches do they need to push to reach a mature protocol. There's no UI, there's no innovation, it's all back-end box standard functionality.

The surface of getting things wrong is quite limited, and the protocol still skips so I actually do not see things getting better from these patches.

Can this be interpreted that Bluetooth is full of security vulnerabilities?

Recent example on my PC:

Intel Corporation - Bluetooth - 1/9/2017 12:00:00 AM - 19.40.1702.1059
Intel Corporation - Bluetooth - 11/14/2016 12:00:00 AM - 19.30.1646.853

First I would citate @TeunVink 's pretty comment. I don't have anything to give it to...

  There's a difference between the bluetooth protocol and its
  implementations. You get patches on the bluetooth implementation in
  Windows 10, that doesn't have to say something anything about how
  secure the protocol is. It could be that the patch provides security
  fixes for the implementation, but also additional functionality for
  specific devices for example.

...except my own findings from a microsoft ex-employee:

  Full Disclosure: I worked at M$ from 2014-2015.

  MS has some very talented programmers. They're not very common, but they exist. The problem is that the entire company is completely
  and totally focused on developing an absurd number of new features and
  products, giving them completely unrealistic deadlines, and then
  shipping software on those deadlines no matter how half-assed or buggy
  it is.

  The idea is that everything is serviceable over the internet now, so they can just "fix it later", except they never do. This
  perpetuates a duct-tape culture that refuses to actually fix problems
  and instead rewards teams that find ways to work around them. The
  talented programmers are stuck working on code that, at best, has to
  deal with multiple badly designed frameworks from other teams, or at
  worst work on code that is simply scrapped. New features are
  prioritized over all but the most system-critical bugs, and teams are
  never given any time to actually focus on improving their code. The
  only improvements that can happen must be snuck in while implementing
  new features.

  As far as M$ is concerned, all code is shit, and the only thing that matters is if it works well enough to be shown at a demo and
  shipped. Needless to say, I don't work there anymore.

Having many patches doesn't surely mean they are all security patches. They can be much probably mainly compatibility and stability improvements.

Microsoft has a strategy that they try to unify their Windows and Windows Mobile development, which means they try to develop both products from the same source tree. It means, improvements to the bluetooth stack of the Windows Phones can also affect the bluetooth also on the desktop OS - they are probably the same source code.

The main security concern behind the Windows Bluetooth implementation are coming most probably from the Windows Phone - on desktop machines, it isn't even turned on most commonly.

Only these reasons I wouldn't say that bluetooth, as protocol would be inherently bad. It is much more probable, that its Windows implementation has more probably compatibility problems (with earlier software / windows versions) and may have also other problems, partially security-related ones.


Does the use of CSRF Tokens as a defense mechanism block all Cross-Origin Requests? I am trying to understand how one can prevent CSRF attacks. From what I have read and understood online, it seems to me that CSRF Tokens or using say the Origin header for CSRF prevention basically blocks all cross origin requests (specifically can be implemented only for those requests that change state such as POST)

Wouldn't this mean that even legitimate cross-origin requests would be blocked?

I just wanted to know if what I have understood is correct.

Thanks!

Wouldn't this mean that even legitimate cross-origin requests would be blocked?

Use of CSRF tokens and checking of Origin or Referer header does not simply block all cross site requests.  It just means that only requests which have the proper CSRF token or which come from an acceptable Origin are allowed by the web application. Thus it also can be used to allow controlled cross-site execution if this is required.


How can you securely use a cloud-based CI/CD server? I'm looking at using a cloud-based continuous deployment server to push production code for my application.

Because it's a cloud based server, this requires me to give them a private SSH key that has access to push the appropriate files to my production server. I figure with the principle of least privilege, this SSH key should allow login to a locked-down user with write privileges to only a few directories. Then the production server can use upstart or other types of scripts that detect the code changes and start running the new code.

Suppose my threat model is that the private SSH key gets leaked from their end. Is it possible to mitigate this risk at all? Even if I lock down the user as much as possible, eventually code that is pushed by the user will be executed by the webserver user (which has greater privileges). So it seems that any leak of the SSH key that I give them will result in the possibility of remote code execution.

Are there any best practices in setting up a cloud-based CI/CD server, or is that just a risk I have to take?

One mitigation you can use is to IP restrict that upload as well - you know where a legitimate upload will come from, after all.  This will mitigate against ssh key loss through means that don't compromise the actual server (ie, backup losses, disk duplication, read only exploits, etc)

You can further mitigate using agreements - that they will follow appropriate security measures, that they will encrypt your data before backing it up, that they patch servers regularly.

I could imagine some sort of one-time-use token that gets added to your source repo project by systems you control and that change being what triggers the build.  Your webserver could reject builds without a valid token or with a token it has seen before.  This may be excessive, however, and is much more complicated. It is likely more appropriate for CI where there is a manual gate before production deploy, rather than CD where it goes in if it passes the tests, as well.


REJECT Nikto Scans With Snort Rules Hoping someone on here knows a way to reject Nikto traffic with Snort rules. I've been having zero luck for days finding this anywhere online. Thanks. Peace.

If you use Official Snort Ruleset then it is already included inside ruleset:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Nikto Web App Scan in Progress"; flow:to_server,established; content:"(Nikto"; fast_pattern:only; http_header; pcre:"/^User-Agent\x3a[^\r\n]*?\(Nikto/Hmi"; threshold: type both, count 5, seconds 60, track by_src; reference:url,www.cirt.net/code/nikto.shtml; reference:url,doc.emergingthreats.net/2002677; classtype:web-application-attack; sid:2002677; rev:14;)


What to say to the webmaster of a site that sends passwords by e-mail upon registration? Receiving an e-mail with my user id and password just after registering on a website is not rare. However, I believe it is bad practice, as it seems those e-mails cannot really be made secure.

Is sending those passwords by e-mail really wrong? I did read a lot about this topic, but can’t find a clear-cut answer.
If it is wrong, how do do I tell
them? Is there any clear reference on this topic?

It's certainly not a secure practice.
But as to whether insecure sites using this practice are worse than other insecure sites, it depends on your users and threat model.

If 50% of your users' passwords are "111111", "qwerty" and "bugmenot", and 45% are equal to their logins, you could actually improve security that way.

If your password reset policy requires nothing but the user's email, which is very common, then any MITM or anyone with access to your or your user's mail has the door open already. However, they're not the only threat...

The real problem is the implications of such a practice. Hopefully the passwords aren't stored in plaintext, but emails get kept in some databases, and these passwords will leak when one gets mined. I get a lot of targeted spam offers to sell out the user DB of a website I run; don't know how many people accept those, but some clearly do.

Of course, if the only thing of value on your website is the users' email addresses, the damage has to be weighted against the mitigation of damage from password reuse for users who don't care.

For a site that has user data of real value, or especially a financial one, any transmission of the password is highly inappropriate. Even if it has to be changed immediately, that one-time login is better done with a one-time authentication token. So it's unlikely that any site following this practice is designed in a secure way.


Does storing bank account-routing number combinations fall under PCI DSS Level 1 compliance rules? I've looked at a number of question/answer threads and docs about PCI compliance, including various results on Google and have not found a definitive answer to this question:

Does a web app fall under PCI compliance rules/regs if it collects the bank account-routing number combination via a web form and passes it along to a 3rd party for persistence/validation (assuming that it also logs the web requests in transit)?

Since PCI stands for Payment Card Industry the short answer is no.

However that information is sensitive so you should treat it like any other sensitive data and store and transmit it in a secure, encrypted form.

PCI is a great baseline for dealing with any secure data so it certainly wouldn't hurt to treat it the same.


Could Mental Cryptography(?) be useful to ordinary users? I recently read about 'Mental cryptography' or 'Metal hash' process from this post: Mental cryptography and good passwords (via this message board http://www.codeproject.com/Lounge.aspx?msg=4911235#xx4911235xx).

I think, main point of this scheme is this: Do not use the same password more than one login.

For this purpose, Prof. Manuel Blum suggest a kind of hashing formula that people could run in their brain (not me).

If I take this advice and devise simplified version of my own hashing formula which will always generate 4 digits and 4 fixed string (ex: 2112$Pwd), will I'm more secure?

In other words, which is more important?

Unique password for every login
Never use trivial password (ex: user name plus one digit)

The two defences you list are meant to protect against two different attacks.

  Unique password for every login

This is meant to protect against a leak of someone else's password database.  Even if the attacker works out your password, it's useless as it only allows access to the single website the leak happened on (which you've probably changed by the time the attacker gets the password).

  Never use trivial password (ex: user name plus one digit)

This protects against any password database leak.  If a password database leaks (and the password is properly hashed) then this makes it harder (and maybe impossible, depending on the entropy of your password) for the attacker to actually reverse the hash and get your password.

This might lead you to believe that a strong password is the most important defence of these two.  However, you cannot guarantee that a website hashes the password correctly.  For example, in the massive Adobe breach recently, the passwords were not salted.  This meant that attackers could reverse a great many hashes very fast.

So you see, your password could leak in plain text, or in a reversible form of encryption; making it easy for the attacker to know your password even if it's strong. In this case, your only defence is making sure you have a unique password for each site.

In the end, it's your choice, but neither defence is to be considered secure on its own.  My recommendation is to use a password manager, to gain strong and unique passwords for each site.