19

I've read a thousand times that a password manager is the best way to secure numerous online accounts, and I think I understand the reasons pretty well. In practice, there is one problem : the ideal solution doesn't currently exist.

Why password managers aren't ideal

The most well-known "cloud" PMs like 1Password and Dashlane are paid and require me to trust a proprietary, closed-source system with the most important pieces of data I have. LastPass, aside from the closed-source problem, has a very bad, half-baked UI, was full of bugs last time I tried, and its interface is only partially translated into my language. It's also a pain to use it with other apps than my browser, as I have to open the browser, open the LastPass extension, search for the entry, copy the username, switch windows, paste, then repeat for the password. Finally, I've read too much about the vulnerabilities that were discovered in it to be comfortable with it, and I usually don't trust "free" (as in free beer) cloud storage.

Then there is KeePass that's the best solution I know of. The main problem with it is that there isn't an iOS equivalent that would be capable of syncing two databases (the iOS apps that are compatible with it just overwrite the remote version with their local one, potentially overwriting changes in the remote one).

In every case, syncing my passwords database with my phone would require either using a proprietary system or using a standard cloud service, which I don't want to use for several reasons (mainly not wanting to have a new background process on my laptop for syncing just one file, and not wanting to make my data available to cloud provides and whoever can read their data, even for an encrypted KP database).

What to replace them with

For all of these reasons, I'm currently trying to go back to using my brain as a password manager. I'm able to remember some reasonably secure passphrases for the few accounts I really care about and I'm working on a password scheme that would be reasonably hard to guess and provide different passwords for different sites. These usually mix a secret value remembered by the user with some information about the site, like its name.

I can make this method work, but then I'm worried about, for example, password leaks on some website with bad security, enabling someone to analyze one or two of my "lower-security" passwords, and guessing the scheme. The main problem to solve seems to be to design such a scheme that would be simple enough to be practical, while resisting to the leak of a few passwords from time to time.

Which brings me to my question : is it possible to create such a good password scheme, and would that method provide security that's not substantially inferior to a well-designed password manager ?

  • 3
    The problem is how to remember them... I can do that for the most important sites, but I have more than 40 passwords to remember in total, which means that I need some sort of mnemonics to remember the numerous other ones. And that mnemonics is a flaw. I'm mainly asking if it's possible to create one that's secure. – Elzo Nov 17 '17 at 20:12
  • 9
    @dandavis Not very secure. It only would take a few stolen passwords to figure out the pattern. – Aaron Franke Nov 17 '17 at 20:22
  • 6
    @dandavis Ydob mentions having over 40 sites to have passwords for, I wouldn't count on all of them being secure. Heck, there are still places I've seen that don't even bother hashing... All it takes is a few untrustworthy site admins, your scheme isn't strictly password reuse, but it's close enough. – AndrolGenhald Nov 17 '17 at 20:33
  • 2
    @dandavis Stolen by MITM attacks, or badly programmed sites that store passwords in plaintext or just encryption. It happens more than you think, even to large companies like Adobe. haveibeenpwned.com – Aaron Franke Nov 17 '17 at 21:11
  • 2
    @everyone: valid (if pessimistic) points. there's also the un-change-able password issue. client-side derivation can mitigate the security complaints. Also consider stenography like using arxjzxgbf instead of stckxchng (one to the left on the keyboard). to prevent target attacks like discussed. – dandavis Nov 17 '17 at 21:39
6

Personally I have ~5 >= 12 character entirely random passwords memorised. These are used for key sites and the password is used between at most two sites and if reused then the two sites have different email addresses and usernames for me..

For other less critical sites I map 3 random 8 character strings + the site name. For example "4QvkmvBt-StackExchange" and I might also have "4QvkmvBt-reddit". I have my own schema for mapping sites to random string. I also get extremely upset with sites whose password policy does not allow me to use this. Personally I view this as secure enough. If ever I became aware one site had been compromised I would replace all passwords using that random string.

This is good enough for me personally. Its not as strong as the passwords a password manager could provide but its also convenient (they are always available - in my head) and good enough. If stored properly by sites they should be impossible to brute force. If somehow someone does obtain a plaintext password the damage is limited. I also have no reason to believe someone would put above average effort into breaking into my accounts.

I dislike password managers because its a single point of failure. Any major password manager will also be mass targeted should a vulnerability be found. However for people that cannot remember long random strings I would still recommend them.

  • I'm curious about why you're appending "-sitename", I don't see any clear benefit to it off the top of my head. – AndrolGenhald Nov 17 '17 at 21:44
  • 6
    @AndrolGenhald - If one were stored poorly on a site that is breached it stops automated tools injecting it into other sites. It also improves them against brute forces on the hash. Most attackers won't attempt adding it to random strings by default. So whilst in theory it doesn't add any real security in practice it does. – Hector Nov 17 '17 at 22:36
  • How do you store the list of websites on which you used each password-class? (needed for replacing all passwords using that random string) – Ángel Nov 19 '17 at 23:47
  • @Ángel - I don't keep a list. Although a text document backed up would be good enough. My general rule is don't put any information I'm worried about leaking on any site that I don't care about enough to remember. – Hector Nov 20 '17 at 11:27
  • @AndrolGenhald I can also see it adding some security in practice. For someone who is blindly cracking md5 hashes from a password leak, 4QvkmvBt is within the realm of crackable for a sufficiently advanced MD5 cracking rig, but 4QvkmvBt-StackExchange is too long. – Conor Mancone Sep 12 '18 at 12:53
3

You can use a stateless (or vaultless) password manager such as https://lesspass.com/. Basically it does what you were doing by hand (it generates passwords as function(master_password,website_name)), only that this time function is a secure hashing function rather than concatenation.

By using a per-website "counter" token, you can change passwords for the same website.

This would solve your concerns, I think.

  • 3
    Where do you save your database of "counter" tokens, and lists of allowed characters for each website (therefore also list of websites you have an account on)? You're back to the original problem. In the case of a password manager with encrypted storage, with your file, if they manager to guess your master password (with nothing else to go on), they will get all your passwords. The same goes for a "vaultless" PW manager, with the added vulnerability that if they can find your password from a dump from some other site, that's information they can use to attack your master PW. – Ben Nov 18 '17 at 22:33
  • @Ben 1. Locally. You can avoid syncing them; they are saved only for convenience. 2. Yes, if they find your master password you are screwed. That's true of every encryption system in the world (apart from two-factor authentication, which we weren't discussing and has other "all eggs in one basket" issues). 3. If you use an insecure password as your master password, no amount of crypto can save you --- see above. – Federico Poloni Nov 18 '17 at 22:49
  • That's exactly my point though. 1. You could keep your PW DB locally too. 2. No additional security from a "vaultless" system. 3. So additional security from a "vaultless" system. At best, it's a wash. With the added (unlikely) attack surface of guessing your master password from any leaked password, which in a traditional PW manager is not even theoretically possible. – Ben Nov 20 '17 at 5:13
  • 1. In a vault-based password manager, if you keep your DB locally, then you need to sync passwords manually on all your devices. With a vaultless one, you just have to re-set a couple of settings in the same way; much easier to do by hand. 2,3. I agree: vaultless password managers are less secure than vault-based, not more secure. (I don't use one myself) I recommended one because OP seemed more concerned about convenience (ease of syncing), not security. – Federico Poloni Nov 20 '17 at 7:36
  • Stateless solutions have usability issues, as different sites have different password requirements. What is site A requires you to have special characters and site B allows only letters and digits? What about minimum/maximum length requirements? You have to tune hash function for individual site, which invalidates statelessness. – el.pescado Nov 20 '17 at 9:20
3

I will diverge by suggesting that you might not need to discard usage of a password manager.

You seem to actually have a technical problem: no iOS app being able to synchronise the database intelligently. However, they seem to be able to copy the files somewhere trustable that isn't a cloud provider (?)

I see a few options available:

Do not sync the keepass files

Do you need all the passwords on desktop and the mobile? Maybe you could do with separate keepass files.

Get the app to implement the feature

Either implement it yourself, if you have the required knowledge, resources and time, or convince someone else to do it. That could range from simply opening a bug report / mentioning the problem on a mailing list to hiring a developer just for doing that.

Generally, attaching a bounty to the request should help, though.

Synchronise manually

You probably don't add passwords too often (as opposed to reading them), so performing it manually should be doable (either by entering the missing entries by hand or by moving the files in the right direction).

Only add entries on mobile

(If your keepass app is able to copy-to-remote)

Generate new passwords only on the mobile version. The desktop one acts as read-only. Thus, as it always have the master version, there is no loss.

Sync on the desktop

(If your keepass app is able to copy-to-remote)

Have the file synchronised by the mobile app to save on desktop on a different folder than the one where you use the local keepass. Then you trigger a smart synchronization between the two files on the desktop (you may copy back to the iPhone or work with a bigger desktop file). Note you could manually run the "daemon" when needed (thus sparing the background process).

3

I'll give you the typical IT answer: it depends. What does it depend on? The level of complexity you'd like to endure to ensure your security.

Several years ago at a security conference, I heard a speaker talk about his password procedure. Each system he logs into has its own password. These are changed every 30 days and he stores the passwords on paper in his safe. That's probably the most secure way to manage passwords. But the PITA factor is really high.

Hector has a good scheme, but it has one failing—it lists the site in the password. Once a password gets compromised, a bad guy can figure out that algorithm and unravel the whole shootin' match.

Remember: the longer your password, the longer it will take to brute-force. Each additional character makes the duration exponentially longer if a bad guy is trying to guess the password.

A good middle-of-the-road solution is to have one password that you use for a lot of sites. Then anything financial or worthwhile gets its own password. So e-mail, bank, and investment accounts all have different unrelated and long passwords. Everything else (vendor web sites, school, the pizza place, etc) would have a "standard" password.

  • 1
    "it has one failing - it lists the site in the password" - Why is this a failing? This is no worse than your suggestion to reuse a single password for less important sites. – AndrolGenhald Nov 17 '17 at 21:47
  • @AndrolGenhald: I consider it a failing because it has a breakable algorithm and appears to be used for all sites, including financial. Under that system, a cracked password for the pizza place would yield a possibility to try for RedneckBank. Under my system, cracking the password for the pizza place would also yield the password for the school portal and some other trivial web sites, but not my e-mail or bank. I'm not under the illusion that my system is perfect. :) – baldPrussian Nov 17 '17 at 22:10
  • 2
    He says he uses separate >=12 character passwords for important sites. Honestly your suggestions seem pretty much the same to me, his just goes into more detail about how he comes up with the passwords. – AndrolGenhald Nov 17 '17 at 22:23
  • 1
    @baldPrussian - All banking sites and critical accounts have dedicated >=12 character passwords. These are for sites where Im not massively bothered if they gain access. If somebody trashes my reputation here for example then worst case I remove it from my CV. – Hector Nov 17 '17 at 22:39
0

TLDR

Use a stateless password management with different master password for each site.


Let's go into detail

The stateless password management methods suggested in other answers has one major flaw, if a person knows your master password he can generate passwords for all your sites. It can be solved by using different master password for each site.

You can store the list of master passwords in the following way or any other way you find comfortable,

  1. Create two lists - one that lists sites and the other lists master passwords.
  2. Use a numeric code to link them. For example list one will contain 1234 - Stack Exchange and list two will contain 1234 - secretmaster.
  3. To access the lists across multiple devices use two different cloud storage with Two Factor Authentication.

Alternatively, you can use a single list. It is a trade off between ease of use and security. Choose what is best for you.

I also recommend to change the master password of a site and thereby the actual passwords once in a while.


Security of this method

Like any method this is not 100% secure but it an improvement over the previous suggestion.

  1. It is unlikely that an unauthorized person can obtain two list from different cloud providers and link them with one another.
  2. Even if they obtain two lists they still do not know what algorithm you are using to produce the site's password.
  3. This way you can also change the password of a single site and still use the algorithm by changing the master password of that site. In previous methods changing master password affects all sites.
-1

Instead of a password manager and cloud storage, I use something like this in a bookmarklet:

Paste this into the url of a new bookmark, and edit the salt (123456789) after pasting:

javascript:function s2a(s)%7Bvar a=new Uint8Array(s.length);s.split('').forEach((x,y)=>a%5By%5D=x.charCodeAt(0));return a;%7Dfunction a2s(a)%7Breturn%5B%5D.slice.call(new Uint8Array(a)).map(x=>x.toString(16)).join('');%7Dcrypto.subtle.digest('SHA-256',s2a('123456789'+location.host)).then(a2s).then(function(r)%7Bprompt(location.host,btoa(r).slice(2,22))%7D);void(0);

As slightly more readable code (JS, run in console from [F12] developer tools):

function s2a(s) {
    var a = new Uint8Array(s.length);
    s.split('').forEach((x, y) => a[y] = x.charCodeAt(0));
    return a;
}
function a2s(a) {
    return [].slice.call(new Uint8Array(a)).map(x => x.toString(16)).join('');
}
crypto.subtle.digest('SHA-256', s2a('this is MY s@lt, use yer 0wn' + location.host))
    .then(a2s)
    .then(function(r) {
        prompt(location.host, btoa(r).slice(2, 22))
    }
);

When run on this site, c5ODI5NDMzMzQxNzRlZG is offered in a copy-able prompt interface.

This performs client-side hashing on an https site using a user-defined salt and the site's domain. Given a decent salt, it should be impossible to reverse, even if the attackers know the code above was used. It's different each site and virtually impossible to correlate between sites.

You should probably not sync your bookmarks if you go down this route, or if you must, prompt() for some user-supplied salt to keep the source code from revealing your formula.

While these kind of self-defined password derivations are secure, there's one major downside: you can't change a single password without changing them all. It's just another option in a field of imperfect options, so I thought I'd put it out there.

  • I'm confused: Are you suggesting to append the derived string to a memorised password? If so you should probably mention that! – Emil Nov 18 '17 at 9:31
  • @Emil: i was suggesting it produce the whole password, but you bring up another angle of attack: instead of a readable domain "salt" used w/ a static password, one could use the above. – dandavis Nov 18 '17 at 10:37
-1

Intro

I've actually been thinking on this a while myself, and I agree that using a password manager isn't ideal for password security.

  1. Because it introduces a single point of failure, which in my book is too great a risk. I don't want to entrust a third party with my security, or place the weight of security for all my accounts onto the strength of one password.
  2. Because you either need to store your passwords in the cloud which is potentially accessible to everyone, or keep local copies and run the risk of losing the data and access to all of your sites with it.

The best solution I can come up with is one that has been mentioned in a few different answers already: using an algorithm to generate passwords. Although it's been previously mentioned, I feel that none of the other answers have quite provided a good implementation of this method yet, nor have they touched on several noteworthy points.

Generating Passwords Using Hashing/Encryption

A secure password generating algorithm should do three things:

  1. Generate a secure password
  2. Make it easy for the user to retrieve their passwords
  3. Be inefficiently reversible without the initial input

So, my solution to this would be to run your password through the following generalized algorithm:

ENCODE(HASH("password" + "salt"))

My ideal suggestion would be to use:

Base85(SHA3-512("password" + "salt"))

Essentially, your password will first be run through a hashing algorithm to generate a random, irreversible output (in this example SHA3-512), and then encoded to give the password a large range of character values which increases it's resistance to hashcracking exponentially (here I've chosen Base85).
I suggest setting the password as the base domain of the site you are trying to log into, and setting the salt as your "password".

A concrete example:

Base85(SHA3-512("security.stackexchange.com" + "MyPassword"))

Preforming SHA3-512 on the string "security.stackexchange.comMyPassword" yeilds

8b6fe2cfd65d5faf4f3babe823afa844a9eb9c36dc6c1459b0f430a0f77318052318ce6b607eab0114f990aa52bb2a7acd06735f8590c2886bbc68ca42d05328

And after running this through Base85 you get

<~3+=dXAMRb-A2Z;U2.g9/1hJOQ@:Ee-1,E?N@5p)#@6%n.3Faj'A7IN-0f1aJ@PDCN1GE5kAiDY)0fUjE1,CXE@q@Q-2D@($@:CoF0f3K&3A=lM2)8WM11<+M@q78O2`!='3&N]M@kp#'2I^-*2E52T1brSq2)@!I~>

I think you could argue the above password is a strong one, and all you have to do is remember "MyPassword".

Altering My Example

Obviously, this concept could be applied with any hashing algorithm and encoding scheme, and whatever pattern you want as the input. Be wary though, the security of your generated password relies on what you choose for the algorithm (as well as your base password!). Some things to note:

  • When it comes to hashing, hashing twice doesn't really add to the security of the password. If you use two different hash algorithms, in theory the resulting hash is only as secure as the weakest one in the chain. Take SHA1(MD5("pass")) for example. MD5() produces a 128 bit hash, where as SHA1() produces a hash of 160 bits. By doing this, you are essentially mapping 2128 inputs onto 2160 outputs. By theory of the pigeonhole principle, at a maximum this algorithm can only generate 2128 possible outputs, which undermines the security of SHA1().
    The same result occurs with MD5(SHA1("pass")), but what about SHA1(SHA1("pass"))? By using SHA1() twice, you are mapping 2160 inputs onto 2160 outputs, which theoretically should be fine, but in practice it is not because of hash collisions. Any two strings A and B that collide on SHA1() will collide on SHA1(SHA1()). Furthermore, two unique hashes SHA1("C") and SHA1("D") may collide on SHA1()! This means that not only will SHA1() output <2160, but it will also have roughly twice the chance at forming hash collisions.
    TL;DR hashing a string twice only weakens the security of that hash, because instead of mapping ∞ onto n bits you are mapping <∞ onto n bits.
  • You could exchange a hashing function for an encryption function, but I would argue that this wouldn't increase the security of the algorithm at all. If we assume both the encryption function E() and the hashing function H() are equally secure, then they're essentially doing the same thing: On one hand E() is using the string "MyPassword" as a key to encrypt the domain "security.stackexchange.com" while on the other hand H() is using "MyPassword" to salt and hash the domain.
    I want to put a disclaimer here that I am well aware of the difference between encryption and hashing. They are two separate types of string permutation, but in the context of generating a password they are essentially the same. If you don't know the difference between hashing and encryption, you can learn more here, and this is another interesting, related article.
  • Changing the encoding is a possibility, but I think Base85 is that sweet spot. If you go with something lower like Base64 (or any encoding scheme that generates output from a smaller pool of characters) you're only making your passwords weaker. You could increase the encoding past Base85, but eventually you start to hit outputs with non-printable characters and issues would arise from there.
    One issue with encoding is that there are sites that actually limit the length and what you're allowed to input for passwords. This is utterly ridiculous because the only thing you should be doing with a user password is hashing it down to a fixed length and storing it. Password fields shouldn't offer any sort of vector for attack, not even SQL Injection because the data should be hashed before it even touches a query. Alas, there are sites out there that restrict password field inputs, so in rare cases Base85 might not work universally.
  • Lastly, it's completely acceptable to use multiple passwords for this solution, and even different Hashing/Encryption algorithms for different sites. If you choose 3 strong passwords and 3 strong Hashing algorithms, you now have 9 generators to draw from! Of course, if you extrapolate too much then you'll find yourself with the exact same problem this method aims to solve, but I believe there is a happy medium to this.
    Perhaps create 3 base passwords to insert into this algorithm, one for sites you don't care about, another for sites you partially care about, and a third for sites with sensitive information on them. Or you could do the same but with different Hashing/Encryption algorithms. The world is your oyster here, as long as you can remember them all, the more the merrier.

The Security of this Method

Theoretically, using this algorithm to generate a password is no more secure than using your password in the first place. This is because if the attacker gets ahold of your base password ("MyPassword"), and assuming the algorithm is public (which it would need to be for this method to become widespread), there is nothing stopping them from generating your passwords for each site you visit.

In practice however, I would argue this method IS more secure. You can look at it from several different attack vectors:

Database Breach
If an attacker were to breach a database and collect the stored password hashes, his only route of attack would be to crack them. Brute force would take too long and a Mask Attack wouldn't reasonably succeed either with the Base85 encoding.
If the passwords weren't hashed (pray for that DB Admin) then the attacker could easily decode the Base85 encoding. But then all he'd be left with is a hash. Although he wouldn't need to crack this hash (or even strip the encoding) to login as you on that site, he wouldn't gain access to any of your other accounts without first discovering your base password.

Man In The Middle Attack
Ultimately, the hashed and encoded password you generate is being sent over the wire to the website. Hopefully that site uses HTTPS, but not all of them do. If an eavesdropper is sitting on your connection and they manage to read this password they can login as you, but like mentioned above it will only be for that site. Without your base password the eavesdropper will have no way to access your other accounts. This is a better outcome than if you didn't generate passwords, because in that case the eavesdropper could login to any account in which you've used the same username/password combo.

Brute Force/Mask Attack
If a malicious actor is attempting to brute force your base password, then your generated passwords will be no more secure than using a regular, non-generated password (assuming the actor knows the algorithm you used to generate those passwords). In this case generating passwords doesn't add any extra security, but it doesn't diminish the security at all either. This attack vector requires you as an individual to be targeted as well, which in practice is much less likely to happen than the above methods. That said, it's still possible, so make sure to choose a secure base password.

Uncovering Your Base Password
As it stands, the ONLY way an attacker could generate the passwords for all of your sites is if they knew your base password. There are only two ways they can get this (without you directly telling them).

  1. Crack the generated hash of your base password
  2. Brute force your algorithm until they come up with your base password

First of all, by attempting #1 you are actually using #2. The most efficient method of cracking a hash IS brute force, so these are essentially the same thing with minor differences.

As long as you have chosen a secure base password, both of these methods should be close to impossible. This is because the attacker would need to come up with your EXACT base password to gain access to all of your accounts. Only with your EXACT base password can an attacker correctly generate your other passwords, hash collisions don't even factor in here.

To explain further, say you have your generated password P1 where P1 = G(S1) and S1 = p + s1 (G = generator algorithm, p = base password string, s1 = salt). If an attacker procured P1 and found some S1' such that P1 = G(S1'), then S1' would HAVE to equal S1 or the attacker wouldn't have access to your other accounts. Just because S1' evaluates to P1 does not imply that S1' will evaluate to P2 where P2 = G(p + s2).

Hopefully I didn't lose anyone with that explanation.

Outro

To specifically answer the OP's questions:

Is it possible to create such a good password scheme?

I think the method I've outlined in my post is a sufficiently good password scheme. It gives you a unique, strong password for every site you have an account on without straining your brain to remember all said passwords individually. All you have to remember is the algorithm and base password(s) you used.

Would that method provide security that's not substantially inferior to a well-designed password manager?

At it's weakest, the method I've given is equally secure to using regular passwords, and a PM to store them.

  • When using a PM, you are essentially encrypting each (password, website) pair for every site with a single key. Using this key gives you access to all of your accounts.
  • When generating passwords, you are essentially encrypting (or hashing) each password so that the only way to get that password is by knowing the key. Using this key gives you access to all of your accounts.

However, at it's strongest, you could reasonably say that this method is more secure than a Password Manager. Namely because You aren't entrusting someone else to keep that base password safe for you. The only thing you have to trust is your brain, and as long as you don't go crazy that's not such a scary thing to do. :)

PS: If there are any oversights to my solution or extra tidbits that anyone thinks I should add, please comment and let me know. I would be happy to improve this answer by editing in any valid points you guys come up with.

  • I think that this is functionally equivalent to what is suggested in my answer and dandavis' one. It solves the vault storage problem, but the main weakness is the one suggested in Ben's comment: given your hashed password for one compromised website, one can try to brute-force your main password quite effectively. – Federico Poloni Nov 21 '17 at 14:54
  • Right, this answer describes a solution that other answers have previously mentioned, but I wrote this because I felt as if none of the other answers were quite adequate. In your answer you provided a solution using lesspass, which is a good option, but you didn't go into detail on the password generation method or discuss the security of using password generation at all. Dandavis gave us a script to run, but he also didn't touch on the security of generation vs using a PM. His answer let the code do most of the explanation work, and you can't just change one password with that method. – FRZ Nov 22 '17 at 22:16
  • Now, when you say that "given your hashed password for one compromised website" an attacker can "brute-force your main password quite effectively" I wouldn't say that's true. At least not effectively, or efficiently. I've addressed this already in the 'Security of this Method' section. This is precisely why I suggested using SHA3-512 or at least an equivalently secure hashing algorithm, to minimize the possibility of a successful brute force attack as much as possible, and said that you still need to choose secure base passwords or this entire process will be pointless. – FRZ Nov 22 '17 at 22:30
  • In fact, you've actually already addressed the issue of weak base passwords in your 3rd point here. – FRZ Nov 22 '17 at 22:31
  • 1
    What I write is true from the point of view of the user. But still it's a weakness: look at it from the point of view of an attacker. You have acquired the passwords DB for compromisedwebsite.com. Compute Base85(SHA3-512("compromisedwebsite.com" + "MyPassword")) and check if it matches a password in your database. You have successfully hacked everyone whose master password is MyPassword. Now you know also the password for their bank account. Bingo! – Federico Poloni Nov 22 '17 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.