Password reset
by Bruno Oliveira
Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/password-reset
Some considerations to keep in mind:
1. E-mail in an insecure channel, for this reason we won’t build any functionality to “remember” the password, only reset.
2. It must be provided over SSL
3. We are not NSA proof, so this is just a prototype to validate ideas.
Details about the prototype:
1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database
2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC), which means there’s no way you can pull the url id back out. Into this way we are avoiding 2 issues: rainbow table attacks and tampering, into other words an attacker will have a hard time to brute force it, as well trying to corrupt the message.
3. This example doesn’t not validate e-mail address or have a login.
- Token table
- id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal)
- sentAt: the date and time when the token was sent to someone else
- expiration: token expiration. Default’s to 1 hour.
- used: if the token was used or not. I implemented it into this way, but being paranoid I would suggest to just delete that record, if the token was used.
- ExpirationTime class: just a class to deal with time and check if the Token has expired.
- TokenService class: just a class to manipulate the tokens into the database
- Endpoint workflow:
- /rest/forgot
1. User input the e-mail
2. E-mail is validated against the database
3. An URL to reset the password is sent
Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -d '{"email”:”john@doe.com"}' -X POST http://localhost:8080/password-reset/rest/forgot
- /rest/reset
1. User sends an HTTP request with the token id
2. The id is validated against the database
3. User is redirected to the reset password page
4. The new password is configured
5. token id is destroyed into the database or disabled
Ex: curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D
--
abstractj
12 years
UPS User Management - Reloaded
by Sebastien Blanc
Hi,
I wanted to start a fresh new thread about user management in the Unified
Push Server, please check below the proposition I made for the next release
(0.10.0) , feel free to comment / ask questions etc ...
(https://gist.github.com/sebastienblanc/6547605)
User Management for the Aerogear Unfied Push
Server<https://gist.github.com/sebastienblanc/6547605#introduction>
Introduction
The goal of this document is to describe how the User Management will be
implemented in the Unified Push Server. Currently there is only one user
created by default when installing UPS. Having the possibility to create
multiple users is a "Must Have" and should be manageable from the Admin
Console. Some roles should also be introduced
<https://gist.github.com/sebastienblanc/6547605#roles--permissions>Roles /
Permissions
There will be 3 different roles in this first version :
- *Admin* : The Admin is like the super-user, it can access all the
features of UPS including the creation of users.
- *Developer* : The developer can create/read/update and delete
Applications/variants.
- *viewer* : Can only 'Read', can be useful for monitoring apps (or for
the future UPS Forge Plugin).
Role / actionCreateUpdateReadDeleteReset pwdUser MngtAdminXXXXXXDeveloperXXX
XXViewer X
<https://gist.github.com/sebastienblanc/6547605#user-management-flow>User
management flow
An Admin can create new user by providing a loginName. This will be
possible through :
- The console
- The REST service
<https://gist.github.com/sebastienblanc/6547605#password-management>Password
Management
At creation, the user will have a default password , i.e 123.
<https://gist.github.com/sebastienblanc/6547605#first-login>First Login
When logging in for this first time, the new created user will be prompted
to change his password.
<https://gist.github.com/sebastienblanc/6547605#reset-password-instruction>Reset
Password Instruction
If a user wants to reset his password, he has to request it manually
(email, post pigeon ...) to an admin. The password will be again the
default one and the user will have to change it again when logging in.
<https://gist.github.com/sebastienblanc/6547605#scope-of-the-current-permi...>Scope
of the current permissions
Currently, a authenticated user can see all the applications / variants /
installations, no matter he is the author or not. There is also no concept
of groups, that may come in the future releases.
<https://gist.github.com/sebastienblanc/6547605#security-implementation>Security
Implementation
Currently, it would be possible to implement this using
Aerogear-Security-Picketlink and with some raw Picketlink :
- Login / Logout / Registration : AG-Security offers all we need
- Roles and permissions : AG-Security offers a secures annotation that
can be used to protect the endpoints.
I know there are some concerns about this last points (Role escalation etc
...) and would like to have advice / feedback on what is acceptable /
doable for the 0.10.0 release (15/01).
12 years
Data Sync braindump
by Douglas Campos
Howdy!
Since we're starting the data-sync sprint, I'd like to bring some of the
ideas that born from the research I've been doing.
Note that those are only ideas that will be validated by a PoC or
something like this (which I'm planning to continue working on after I'm
back from PTO)
I envision a layered approach:
1) CouchDB Sync Protocol
This is an approach that I really like a lot - it has lots of common
things with git (keeping SHAs of the document's state and history of
changes (until you compact your history)). The main advantage is that we
can re-use all the nice algorithms we already have on the git lands to
solve conflicts.
2) OT/EC
This is really nice & well-known, but I think it would apply better for
individual fields into a document.
3) Crypto signatures
We could have ed25519 signatures on the changes, making it potentially
safer to decide who should win a change conflict based on rules that
goes beyond simple merging strategies (business roles?)
All this 3 layers could live on top of a very simple JSON protocol,
which would allow us to evolve it gradually (I know this is prone to not
be super efficient, but I don't want to optimize prematurely, and JSON
compresses really well)
Thoughts?
Don't forget to read Summer's thread on this. (can someone reply with
the link?)
--
qmx
12 years
[aerogear-android] Skip SQLStoreTest when running on OSX and Java 1.7
by Tadeas Kriz
Hey,
I’ve been investigating the issue with SQLStore testing through Robolectric and this is what I’ve found.
Those tests run correctly on linux with both Java 1.6 and Java 1.7 and also works on Mac OS X with Java 1.6. This unfortunately doesn’t apply for the Java 1.7 on Mac and the test is failing. And because I think that this test should definitely not be @Ignore-d all the time, I’ve come up with following solution.
In JUnit, there’s a way to decide whether to run a test or not in runtime, based on org.junit.Assume. This way, we could easily ignore the SQLStoreTest when running on Mac OS X with Java 1.7, but leave it on other platforms. I’ve already taken the liberty to write this down and I’ve bundled it into the PR [1] which is fixing the doubly-called Callback#onSuccess bug (AGDROID-150).
What do you guys think about this solution, or should I say workaround? Of course it’s not perfect, it would be cool if we could run even the SQLStoreTest on all platforms without any difference, but right now it seems to be a incompatibility of SQLite with Mac’s Java 1.7.
1 - https://github.com/aerogear/aerogear-android/pull/120
—
Tadeas Kriz
tkriz(a)redhat.com
12 years
