
Show HN: Forgiva – Never saves your passwords but regenerates them - marcusfrex
https://forgiva.com/
======
SloopJon
As I see it, the main benefit of deterministic password generation is the
convenience of not needing a password database. Indeed, if the scheme is
simple and/or portable enough (e.g., PBKDF2) you can implement it from scratch
in a minute or two, depending on what software you have handy. The convenience
breaks down as you need to maintain additional state: password rotation, site-
specific password rules, etc.

Forgiva is based on the premise that a password generation scheme is more
secure than a password database. I'm unconvinced in general; from what I see
in the FAQ and the Ruby code on Github, even less so for this particular
implementation. Spamming the input with an array of whatever OpenSSL
algorithms Ruby happens to make available, rather than using a memory hard KDF
like scrypt, is a bad smell.

~~~
marcusfrex
>> Spamming the input with an array of whatever OpenSSL algorithms Ruby
happens to make available, rather than using a memory hard KDF like scrypt, is
a bad smell.

Sooner or later key-derivation schemes gets outdated and requires a better
version as happened to bcrypt [1] and will happen to scrypt [2].

It is not "whatever OpenSSL provides" but just combining strong algorithms
over to spread the "getting outdated" risks. Think like you are investing your
money? Would you prefer betting on just one thing or spreading it over various
different investment opportunities?

[1] [http://www.unlimitednovelty.com/2012/03/dont-use-
bcrypt.html](http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html) [2]
[http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-
scryp...](http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html)

~~~
tptacek
Not only did that _not_ happen to bcrypt, but the whole point of bcrypt is
that that _doesn 't_ happen: it's an adaptive hashing scheme, which means it
comes with a dial you can turn to up the hardness as computers get faster.

I would be nervous about taking password storage advice from someone who
thinks bcrypt "got outdated and requires a better version".

We had a Password Hashing Competition because people realized that password
hashing and KDFs had become an important topic that hadn't received
significant formal study. Similarly: we're having a CAESAR competition because
people have recognized the importance of all-in-one authenticated encryption
constructions. The existence of CAESAR, AEZ, NORX, &c doesn't mean that
Poly1305-AES is "outdated and requires a better version".

~~~
marcusfrex
Probably i should explain what i meant with "got outdated and requires a
better version" sentence. It is a race and as stronger algorithms comes to
life -and stronger attack methods invented against them-, others gets simply
weaker and weaker just like happened to MD2 and then MD4 And then MD5.

Sorry for misunderstanding.

~~~
tptacek
MD4 and MD5 didn't get easier and easier to crack due to cryptanalytic
advances; it got easier to _generate collisions_. That's a serious problem for
a cryptographic hash, but depending on the construction you're using, it might
not have anything to do with MD5's suitability as a password hash. There's no
password hash cracking tool I'm aware of that takes advantage of MD5's
weaknesses.

So, no: this isn't happening with bcrypt.

------
arthurfm
> To crack a password with 70 bit entropy on a MacBook Pro Early 2013 it will
> take ~6 million years to complete all combinations on Normal complexity. On
> Intermediate complexity it will take ~24 million years and on Advanced
> complexity it will take ~280 million years to reach all combinations at
> minimum.

If you were cracking a password wouldn't it be significantly faster to use
GPU(s) rather than CPUs [1]? If so, why bother mentioning how long it would
take on a CPU at all?

[1] [http://arstechnica.com/security/2012/12/25-gpu-cluster-
crack...](http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-
standard-windows-password-in-6-hours/)

~~~
curun1r
> If you were cracking a password wouldn't it be significantly faster to use
> GPU(s) rather than CPUs?

When you're dealing with time scales greater than a decade, probably not. The
right answer is almost always to wait until future hardware is available that
can crack the password significantly faster than our current CPUs and GPUs.
Whether that's quantum computers or just faster iterations of the kind of
stuff we've got now doesn't really matter...the time spent waiting for new
hardware is insignificant compared to the time spent waiting for calculations
on current hardware to complete.

But I agree that it's disingenuous to list numbers like that because they're
meaningless and aren't at all the answer to the "How soon can my password be
cracked?" question.

~~~
web007
2^70 / 6,000,000 years / 365.25 days / 24 hours / 60 minutes / 60 seconds =
6.2 million reference guesses per second.

Modern multi-GPU instances are 560,000x faster, 350 billion guesses per
second. So that gets you to 6 million years / 560,000 = ~100 years. So
"decade" isn't accurate in this case, but only because of the awful comparison
to begin with. Comparing a 2013 CPU to even a 2013 GPU will give you a 100 or
1000x bump easily, and since this is a case of "embarrassingly parallel"
operation your scale is much smaller than expected.

Also note: 350 billion is for NTLM in 2012. I can't find equivalent stats for
modern GPUs from a few minutes of searching on my phone, but I know they're a
factor of 2-10x better, so 2^70 is easily within reach.

------
tptacek
I'm reading the open source code and this thing is... odd. For instance: it
has a "simple", "intermediate", and "advanced" password complexity, and
depending on which you choose, it uses SHA1, SHA2-256, and SHA2-512 for the
PBKDF2 hash. What does password complexity have to do with the strength of the
algorithm used to generate passwords?

Also: it's 2016. Why is this using PBKDF2? If PBKDF2 is what you've got and
you're protecting a website, that's fine, but this is a password manager.

Is the "commercial" version of this also Ruby code wrapping OpenSSL?

~~~
marcusfrex
>> What does password complexity have to do with the strength of the algorithm
used to generate passwords?

It is not the algorithm only but if you can look a little bit more closely, it
is iteration count too. It uses 1.000 times and 10.000 times more iterations
respectively.

Plus, depending on complexity, character set range enlarges.

>> Why is this using PBKDF2?

We would like to use more industry-standart way of things rather than
individual works.

>> Is the "commercial" version of this also Ruby code wrapping OpenSSL?

Commercial version is purely written C version of it and backed up with
OpenSSL on some cases.

~~~
tptacek
I don't think I asked the most important question clearly enough:

Why do simpler passwords get a different construction? What does password
complexity have to do with KDF hardness?

~~~
marcusfrex
It's probably because different understanding of same terms. With "complexity"
word we mean hardness to generate. It doesnt adds up more algorithms but
character sets and hashing algorithms for PBKDF2 respectively.

~~~
tptacek
Why, exactly, would a user _ever_ want to generate a password with a weaker
KDF?

A password with lower levels of string complexity might make sense ---
1Password's strong passwords can sometimes be rejected by crappy websites. A
password that sacrifices cryptographic strength in order to save a few tens of
milliseconds of KDF, though, makes _no sense at all_.

Also: really, you should not be using PBKDF2.

~~~
aparadja
Honest question: what's wrong with PBKDF2?

~~~
gakada
It's much weaker. Only reason for a password manager to use it is laziness or
ignorance.

------
blowski
As an end user, I don't care about how the passwords are stored. I care mostly
about two things:

1\. How hard it is for someone to steal them 2\. How easy they are to retrieve
when I need them

I'm currently really happy with 1Password on both counts, and I don't really
understand why I should move. A competitor would need to establish that they
are at least as secure as 1Password, and this landing page doesn't do that at
all. For all I know, it's been built by a nefarious hacker or some junior
Node.js developer who's just discovered security.

Has it been audited? What is the roadmap for the project? These things are
much more important than some technical explanation that I didn't really
understand.

~~~
marcusfrex
Theoretically stored passwords are not safe at all. Sooner or later they will
get stolen if it is the case.

Forgiva is actually big brother of kyle
([https://github.com/esurharun/kyle](https://github.com/esurharun/kyle)) which
has been at use for nearly 2 years and experienced and tested a lot.

Yes, you are definitely right on that we should put roadmap on webpage.

And no we are nor "nefarious" hackers neither junior NodeJS developers. :)

~~~
danieldk
_Theoretically stored passwords are not safe at all._

What does this even mean? Aren't they as safe as the cryptography being used
(key derivation scheme, encryption method, etc.)?

(Of course, if a machine is compromised with a keylogger, it's pretty much
game over anyway. Unless you use a hardware authentication token.)

~~~
marcusfrex
>> What does this even mean?

Again "theoretically" all encryption methods prone to brute-force attacks. And
plus, encrypted storages indirectly reveals "encryption passwords" on
succeeded attacks.

~~~
kevhito
And if you go that path, "theoretically" an attacker might simply guess your
password on the first try when attempting to log in as you, so password
"storages" and "brute-force" has nothing to do it.

~~~
marcusfrex
You are mistaken on one think: it is not just being it "theoretically"
possible but likeliness -or hardness- of it.

If the possibility of an attacker guessing my password at first try is one in
a billion -or trillion- chance, then we can say it pretty secure. But hacking
a cloud with a possible zero-day flaw and cracking a password database is not
that hard if we compare it with your example.

~~~
kevhito
I was responding to this assertion:

> all encryption methods prone to brute-force attacks

The chance of succeeding within our lifetime with a brute-force attack against
modern encryption is far less than one in a trillion. So in your words, it is
far better than "pretty secure".

------
SpendBig
Your password will never be secure when you store it on someone else his disk
or let someone else encrypt your password. Its not a matter of how, but when
there will be a way to retreive those passwords by anything but you.

And its not just that, everything you use your passwords for these days, is
stored on some sort of storage in a cloudy architecture. Scattered all over
the world in thousands of datacenters. You probably are currently trusting
thousands of people working over there, but you dont even know these guys.
Terrible imho..

~~~
SNvD7vEJ
What do you mean?

This solution does not store passwords at all, if I understand it correctly.

So whining about storing them on "someone else disk" is a bit odd, don't you
think?

~~~
SpendBig
In the overview, it says on cloud or local. Which made me think, why would you
even suggest storing this on a cloudy device when your offering a password
manager.

~~~
icebraining
_In the overview, it says on cloud or local._

Where? I don't see "cloud" anywhere on that page..?

------
zck
From the FAQ ([https://forgiva.com/faq](https://forgiva.com/faq)):

> How about for sites with restrictive password requirements?

> Passwords, generated by Forgiva are offered with 16 characters minimum (you
> can go up to 32 characters by default) of length and 70 bits of entropy
> guaranteed on normal complexity level. And it is called on strong level for
> financial institutions and military grade applications.

> Thus it is not expected for any site to deny Forgiva generated passwords.

This seems naive, at best. If you can't store an eight character alphanumeric
password, you're not usefully managing passwords.

------
AdmiralAsshat
A couple thoughts that came to mind as I was reading it:

1) How is this safer than a standard password manager with TOTP-based 2FA? The
second token, either produced by TOTP or something like a Yubikey, would guard
against keyloggers, since the one-time code is useless after it has been
entered.

2) How is the certificate generated, and what is it based on? Is the cert
unique per device, or would I copy it to my other devices that need to access
Forgiva ala a public key?

3) There are some typos and other grammatical weirdness on the page that
suggests English is not the writer's first language. That's fine, but it looks
unprofessional. I can make some proofreading suggestions if you feel inclined.
I don't really believe in this product, but I'd prefer it to be judged on its
technical integrity rather than the quality of its marketing, so I'd be happy
to help polish it up.

~~~
marcusfrex
>> 1) How is this safer than a standard password manager with TOTP-based 2FA?
The second token, either produced by TOTP or something like a Yubikey, would
guard against keyloggers, since the one-time code is useless after it has been
entered.

No matter how many factors you are using, sooner-or-later you pass it with
keyboards.And that step may be intercepted and you may think that you sent the
second token to the other-side but failed.

I can provide you a special investigation of Sceptive to show how 2-factor-
authentications has been bypassed by malwares targeting Eastern-Europe banks.

>> 2) How is the certificate generated, and what is it based on? Is the cert
unique per device, or would I copy it to my other devices that need to access
Forgiva ala a public key?

It is not unique per device. You can copy it to all devices you use no matter
what.

>> 3) There are some typos and other grammatical weirdness on the page that
suggests English is not the writer's first language. That's fine, but it looks
unprofessional. I can make some proofreading suggestions if you feel inclined.
I don't really believe in this product, but I'd prefer it to be judged on its
technical integrity rather than the quality of its marketing, so I'd be happy
to help polish it up.

It would be an excellent help, we are very unprofessional on language and
marketing -as you well see-. Can you please send an e-mail to us at
info@forgiva.com to tell us our mistakes?

------
SNvD7vEJ
How does this compare to the KeePass family of pw-managers? (Besides that
Forgiva is closed source and KeePass is open source.)

 _Fixes poor passwords, accessibility and storage problems with highly secure
way._

What does that even mean?

~~~
buro9
The way I read it... it's a password manager that doesn't store passwords
(centrally or locally).

Instead it regenerates the password each time.

i.e. password for HN may be: some trait of HN (domain?) + some salt + your
identity (cert?) to always produce the same password.

I didn't understand it all from the site, the explanations and broken English
didn't really elucidate. But... if my understanding was right, I wondered
about how to handle cert changes or key rolling, etc. There seemed to be a
mentioned mechanism for this, but again I didn't really understand that from
the description.

Gist though: No generated and stored passwords, but a pattern to always
generate the same password for a given site.

~~~
cauterized
What happens then if you want/need to rotate your password?

How does it deal with stupid password format restrictions?

~~~
RubyPinch
the salt gets changed

so, either password database + master password gets stolen, or salt database +
master password gets stolen

~~~
jjnoakes
Except if the master db is stolen without the master password, one can throw
guessed passwords at it and know when one worked (i.e. the db becomes
readable).

Throwing passwords at a salt db gets you... what?

------
tf2manu994
What would happen if the site's domain changes? Or my email changes? Or
something else about the metadata changes?

Now what if this happens on a site where you can not reset passwords, such as
blockchain.info, am I SOL?

I like storing passwords becuase I have 100% certainty that it won't just
magically generate the wrong one.

------
KirinDave
The Windows 64-bit installer is giving a bad signature even though its SHA256
installer hash appears to be correct.

It _looks_ like they used SHA1 checks in the installer. I suspect the author
doesn't realize that older Win installers that use SHA1 are blindly rejected
by Win10 as a security measure (mostly because it's so feasible to game).

It is a very poor introduction to the application on the majority platform.

~~~
marcusfrex
Actually installer compiled using Visual Studio 2015 on Windows 10 platform.
Nothing specifically edited to the way of SHA1 but we fix it on next release.

>> It is a very poor introduction to the application on the majority platform.

Yes you are right it can be better and will be.

------
ninov
I wrote something similar some time ago:
[https://addons.mozilla.org/de/firefox/addon/masterkey/](https://addons.mozilla.org/de/firefox/addon/masterkey/)
[https://github.com/ninov/masterkey-
firefox](https://github.com/ninov/masterkey-firefox)

Or as android app:
[https://play.google.com/store/apps/details?id=de.ninov.maste...](https://play.google.com/store/apps/details?id=de.ninov.masterkey&hl=de)

It works by using SHA256-HMAC on the service name with your master key as key
and then encoding it in Base85 or Base62 (if you don't want special
characters)

------
nautical
This is similar to masterpassword . They have a mobile app and desktop app .
Moreover they are completely free .
[http://masterpasswordapp.com/](http://masterpasswordapp.com/)

~~~
zerognowl
+1 for masterpassword. I always loved the concept of brain vaults. One thing
about masterpassword is that I don't trust the clients and I can't inspect
what's being logged when I fire up the app. The iOS app is closed source and
proprietary and although the idea is great, the clients are not to be trusted.
Get yourself a copy of the Javascript client, and place it in a secure VM so
you have full oversight of what the code is doing. And don't let the
application talk to the internet...

------
ryan-c
I don't have the time to review the design of this right now, but is there
anything to stop attempts to crack the master password from a plain, or even
hash of a derived password?

The encrypted password database is an advantage. You have to steal it to be
able to even try cracking. If it's fully deterministic, anyone with any output
can go nuts trying to crack the master password, and then get all other
credentials.

------
mgleason_3
At first I wondered if it was a spoof. However, it could be incorrect grammar:

> If you suspect against keyloggers or malware, Forgiva presents a visual
> confirmation ystem which leaves less hope for the attackers.

But maybe it's actually phishing?!?:

> And if you get registered, Forgiva uses your registration signature to
> generate special passwords for you. That means for a successful attack it
> will require keyboard and monitor access, plus a file system gain too.

------
Fightback
Cool idea, but the main gripe I have with it is that the passwords it
generates are clearly not made for remembering, but regenerating them takes
multiple seconds.

------
Walkman
These security experts forgot one really important thing: usability. I'm not
going to wait minutes for one password to generate!

------
Canada
How does this handle situations where the generated password isn't accepted by
the site? eg. Is too long, absolutely must have at least one symbol and one
number, etc.

How does this handle changing passwords? How can I know from the master secret
that xyz.com is on the 4th password?

~~~
marcusfrex
>> How does this handle situations where the generated password isn't accepted
by the site? eg. Is too long, absolutely must have at least one symbol and one
number, etc.

You can specify password length if it gets too long and it's character set
provides symbols, numbers and letters in it.

>> How does this handle changing passwords?

It has a renewal mechanism to switch to a new password.

>> How can I know from the master secret that xyz.com is on the 4th password?

Can you explain more about what you mean?

~~~
Canada
Okay, so the password generation is deterministic, based on a single secret I
need to remember right?

So then there has to be metadata to list the site domain, username, which
generation of password, which characters are allowed or disallowed, length,
KDF difficulty, etc? Where is that information stored?

What I'm getting at is with a brain wallet I only need to remember my secret
and know the algorithm used to generate the key. With this it seems like you
need a database to store more information, and without it, it's difficult to
get your passwords back.

------
redpanda_ua
Why buy that, when there is open-source and free
[https://ssl.masterpasswordapp.com/](https://ssl.masterpasswordapp.com/)

------
tluyben2
I was planning to write one as I do not like existing ones but time is a
slight issue: without versions for all platforms and some way to keep them in
sync it is hard to switch...

------
boot13
This seems similar to Master Password
([http://masterpasswordapp.com/](http://masterpasswordapp.com/)).

~~~
marvel_boy
And Master Password is free software (GPLv3)
([http://masterpasswordapp.com/](http://masterpasswordapp.com/)).

------
burgerdev
> To crack a password with 70 bit entrophy

Consider proof-reading the website: I wouldn't trust someone to do my crypto
who can't spell the basics.

~~~
marcusfrex
You are definitely right.

------
max_
Does this implement Shamir's Secret Sharing?

~~~
marcusfrex
No. Why should it?

~~~
max_
added layer of security

------
Grangar
Does this also support shared folders for teams?

~~~
marcusfrex
We are working on Enterprise version of it which will be having this option.

------
dsego
I use getvau.lt, how does this compare?

~~~
marcusfrex
Same strategy but Forgiva doesn't just use one key derivation algorithm (such
as PBKDF2) but plus various hashing and encryption algorithms too.

And at the same time you may forget the options you used in Vault, it is not
an option in Forgiva.

~~~
icebraining
_plus various hashing and encryption algorithms too._

Is there any evidence that using multiple algorithms has any benefit over
simply increasing the cost factor on one?

~~~
RubyPinch
assuming combined correctly

A( B( C(X) ) ), if A becomes broken in the future, its still

B( C(X) ), as opposed to just revealing X straight away

~~~
marcusfrex
Yes, definitely you are right.

And at the same time using various other methods "depending on the master key"
makes it impossible for an accurate time and process estimation for brute-
force attacks.

------
huxflux2003
No mobile apps?

~~~
marcusfrex
Upcoming.

And planning to make it available as Telegram Bot.

------
amingilani
Semi OT, I wrote this satircal piece on how passwords are dead yesterday:
[https://news.ycombinator.com/item?id=12613433](https://news.ycombinator.com/item?id=12613433)

